Cybersecurity compliance, explained.

The word 'compliance' hides an important distinction. Some frameworks are voluntary and commercially driven — you pursue them because customers ask. Others are contractual conditions of doing a particular kind of business. Others still are law, and apply whether or not anyone asks you about them.

Confusing these leads to real mistakes: treating a legal obligation as a sales exercise, or spending on a certification no customer requested while a statutory duty goes unaddressed.

SOC 2 produces a report, not a certificate. You select the trust services criteria in scope and describe your controls; an auditor tests whether those controls were designed appropriately and, in a Type II report, whether they operated effectively over a period of months. Two SOC 2 reports can describe very different control sets, which is why reading the report matters more than seeing the logo.

ISO 27001 certifies a management system: that you have a defined scope, a risk assessment methodology, treatment plans, management review and continual improvement. It is less about any specific control and more about whether security is systematically managed.

Neither is inherently superior. SOC 2 is the common request from North American enterprise buyers; ISO 27001 is more frequently expected in Europe and in public-sector procurement. Some organisations end up holding both because their customers do not accept substitutes.

Vendors advertise 'SOC 2 compliant' or 'HIPAA compliant' products, and the phrasing is misleading in a specific way. A supplier can be compliant itself, and its features can help you meet requirements, but the obligation attaches to your organisation and your processes.

Most requirements are organisational rather than technical: a named owner for risk decisions, evidence that access is reviewed, a documented incident response process that has been exercised, records showing that identified weaknesses were assessed and either fixed or explicitly accepted.

This is where security testing genuinely earns its place in a compliance programme. Testing platforms produce three things auditors reliably want — dated evidence that testing occurred, severity-rated findings showing risk assessment, and retest records proving remediation. What they cannot produce is the decision trail behind them.

Across frameworks the requests converge on a short list, and it is far less technical than most teams expect.

Start with obligations you cannot decline. If you process personal data, data-protection law already applies; if card data touches your systems, PCI DSS already applies through your payment contracts. Address those before pursuing a voluntary certification.

Then follow demand rather than ambition. Pursue SOC 2 or ISO 27001 when a specific deal or market requires it, because both are ongoing commitments — surveillance audits, annual reports, continuous evidence collection — not one-off projects.

Underneath all of it, the same fundamentals from the small-business stack do most of the work: enforced multi-factor authentication, managed devices, tested backups, least privilege, and testing with verified remediation. Frameworks largely ask you to document that these exist and are managed.

Audit findings cluster around documentation rather than technology. Controls exist but were never written down; access reviews happened informally with no record; a critical finding was accepted as a risk in a meeting nobody minuted; an incident was handled well and never documented.

The practical fix is unexciting and cheap: decide where evidence lives, make one person accountable for it, and record decisions as they happen rather than reconstructing them under audit pressure. Teams that do this find their second audit dramatically less expensive than their first.