Security Compliance Engineering: ISO 27001 and SOC 2

A security compliance framework is two things bolted together: a set of controls somebody agreed are reasonable, and an obligation to prove those controls ran over time. The proof is the expensive half. Engineering teams usually have most of the controls already and almost none of the evidence, which is why the first audit feels like archaeology.

Compliance is a floor verified by a third party. It is not a measure of how secure a system is, and passing an audit does not mean an attacker would fail. Held honestly it is still useful: it forces ownership, cadence, and written decisions onto work that otherwise stays informal.

What a Framework Actually Is

Strip the branding and every framework has the same engine:

• Define a scope — which systems, environments, data, and people are inside the boundary.
• Assess risk against that scope, using a method you can describe and repeat.
• Select controls that address the risks, and record why you excluded the ones you excluded.
• Operate the controls continuously, which is the part that is actually hard.
• Produce evidence that they operated, and hand it to someone independent who tests a sample.

Notice that only the middle step is a security activity. The rest is a records-management problem, and it should be engineered as one.

SOC 2 and ISO 27001 Compared

These two are frequently spoken about as interchangeable. They are not the same kind of object at all.

The engineering consequence is the same in both cases: controls have to run on a schedule, and each run has to leave a durable trace. The difference is mostly in who signs, what they sign, and how the scope is written down.

Design Versus Operating Effectiveness

An auditor asks two separate questions about every control. Is it designed to address the risk? and did it actually operate, every time it was supposed to, across the whole period? A team can pass the first question with a policy document and fail the second with a single skipped quarter.

Testing is done by sampling. The auditor picks periods or records at random and asks for the evidence of that specific instance. This has a blunt implication that catches most first-time teams: a control you started operating two months before the window closes has an exception for the rest of the window, and no amount of retroactive tidying fixes it. Evidence has to be generated at the time the control runs, because it cannot be manufactured afterwards without being a fabrication.

It also means an exception is not a catastrophe. Findings are normal. What is not survivable is a finding plus a record that appears to have been created after the fact.

Evidence as a System

Treat each control as a small pipeline with a schema, rather than as a folder somebody fills before the audit:

control:        "Production access is reviewed quarterly"
  owner:        Head of Platform            ← a person, not a department
  system of
  record:       identity provider           ← where the truth lives
  artifact:     group membership export +
                reviewer decision per row
  produced by:  the review workflow itself  ← a by-product, not a screenshot
  cadence:      quarterly, calendar-driven
  retention:    the full audit period + margin
  test the
  auditor runs: pick N periods at random;
                was the review DONE, by the
                OWNER, and were removals
                actually APPLIED?

The strongest evidence is a by-product of work that had to happen anyway. Access reviews export from the identity provider. Change management falls out of pull-request approvals and deployment records. Vulnerability management falls out of the scanner and ticket history. Infrastructure state falls out of plan-and-apply logs. Onboarding and offboarding fall out of the ticket workflow. Backup and restore evidence has to come from an actual restore test, because a successful backup job proves only that a job ran.

Screenshots are the weakest form of evidence and the most common. They cannot be re-derived, they lose context, they age badly, and assembling hundreds of them at the end of a period is the single largest avoidable cost in the whole exercise.

Scoping

Scope is the highest-leverage decision in the programme and it is made early, usually by people who will not carry the cost. Every system inside the boundary inherits every control. Every team inside it inherits the cadence.

Three scoping mechanics are worth understanding before the first conversation with an auditor. The system boundary defines which environments, repositories, and supporting infrastructure are in play — a shared build system usually pulls itself in, whatever the intent. Vendors and subservice organisations can be handled by carving them out of the description and relying on their own report, or by including them and testing their controls yourself; carve-out is common, but the report you rely on has to be read, not filed. Complementary user entity controls are the obligations a provider pushes back onto you in their report — the things that only work if the customer configures them correctly. They are frequently ignored, and they are exactly where a shared-responsibility gap turns into a real incident.

The default failure is over-scoping: pulling in development environments, experiments, and unrelated products so that the report sounds impressive, then discovering that every one of those systems now needs access reviews, change records, and vulnerability SLAs forever.

Failure Modes

When It Is Worth It

Pursue a formal framework when a deal or a regulator requires it, when customers are repeatedly sending long security questionnaires that a report would answer once, or when the organisation genuinely needs an external forcing function to make ownership and cadence stick. Those are good reasons and the cost is usually recovered in sales cycles alone.

Delay it when the product has not settled, when the scope would freeze an architecture you intend to replace, or when the honest alternative is to spend the same effort on controls that reduce more risk than they document. It is entirely defensible to run the controls, keep the evidence, and not buy the audit yet — the reverse, buying the audit and not running the controls, is the expensive mistake.

A word on honesty, because it is the one irreversible failure here: never sign a description of a system that does not match what the system does, and never present reconstructed evidence as contemporaneous. Everything else in an audit is negotiable; those two are not.

Checklist

• Scope written down: systems, environments, data, teams, and explicit exclusions
• Every control has one named human owner on the team that performs it
• Every control has a cadence and an alert when a scheduled run is missed
• Evidence is a by-product of the work, pulled from a system of record
• Risk assessment method is documented and has actually been run
• Access reviews cover applications, not only the identity provider
• Restore tests performed and recorded, not just backup jobs
• Vendor reports are read, and their user-entity obligations are assigned
• Exceptions logged with an owner, a rationale, and a remediation date
• Nothing in the system description is aspirational

Related reading in this section: identity and access management produces most of the access evidence, application security and DevSecOps produces the change and vulnerability evidence, zero trust architecture produces per-request decision logs, and threat modeling supplies the risk input the framework assumes. The wider compliance and governance section covers the non-security frameworks, and Security & Compliance is the section index.