SOC 2, ISO 27001 and PCI: what they actually ask of your pipeline
In plain terms#
SOC 2, ISO 27001 and PCI DSS are the three most engineers meet. They are different in scope and identical in shape: each describes controls an organization should have, and each is assessed by somebody checking that yours exist and operate.
None of them says "run a SAST tool". Almost none names a technology at all.
Why it matters#
That vagueness is the source of most of the confusion, and it cuts both ways.
The good news: there is no shopping list. No framework requires a specific vendor, and anyone telling you their product is required for SOC 2 is selling something. You choose the control; the auditor assesses whether it works.
The bad news: "do you check your code for vulnerabilities before release" is easy to answer yes to and hard to evidence. The gap between having a scanner and having a control is the whole job, and it is where most engineering teams are surprised.
Having a control, versus having a tool#
A control has four properties an auditor will look for, and a tool by itself has one of them.
- It is defined. Somebody wrote down what is checked and what is unacceptable. A scanner with default settings is not a policy; it is a default.
- It operates consistently. Every release, not when somebody remembers. A check that runs on some branches is a control with a hole in it, and the hole is where the auditor points.
- It produces evidence. See audit evidence, something that stands on its own, later, without you narrating it.
- Exceptions are governed. Findings get accepted; the question is whether that decision has an owner and a date. See risk acceptance.
Most teams have a scanner. Fewer have a written threshold. Fewer still can show the last twelve releases were held to it.
What each framework wants here#
Broad strokes, and no substitute for reading the criteria you are being held to.
- SOC 2 is about whether the controls you described operated over a period. There is no fixed list. You assert your controls, and the audit tests them. A Type II report is specifically about operation over time, which is why a control that ran inconsistently is worse than one you never claimed.
- ISO 27001 wants a management system: risk assessment, controls chosen in response, and evidence of review. Annex A includes secure development and vulnerability management, but as objectives to meet rather than tools to buy.
- PCI DSS is the prescriptive one. It names requirements around secure development and addressing vulnerabilities in software before release, with more specificity than the other two, and applies only to environments that touch cardholder data.
The common thread: all three care more about consistency and evidence than about which scanner you chose. A well-documented Trivy in every pipeline evidences better than an expensive platform three teams use inconsistently.
The two failures that come up in every audit#
Inconsistency. The control exists on the main service and not on the two acquired ones. This is easy to create and hard to see, because the tooling is per-repository and nothing takes the overall view.
Silent skips. A check that failed to run and reported nothing. Green build, clean report, missing control, and the artifact does not distinguish it from a genuine pass, because it is the same failure that makes evidence untrustworthy, arriving from a different direction.
How Draugr fits#
Draugr will not make you compliant, and no tool will: the obligations are yours and the judgement about them is yours.
Where it helps is the mechanics that the frameworks care about and engineers usually find tedious. The policy is declared in a descriptor rather than living in a wiki. What is checked and what is unacceptable, versioned alongside the code it governs. The same descriptor runs in every pipeline, so consistency is a property of the file rather than of somebody remembering. Every run produces a report you can keep. Exceptions carry a reason, an owner and an expiry. And a control that could not run is an error, never an absence, which is the failure mode that most often turns an audit finding into an argument.
Deciding which framework applies, which findings are acceptable and who signs off stays with the people accountable for it. Those are not technical questions. What Draugr does is make each of those decisions cheap to evidence: the policy is a file somebody reviewed, the gate applies it identically everywhere, and every run leaves behind the record an assessor asks for.