SOC 2, ISO 27001 and PCI: what they actually ask of your pipeline
On this page
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.
| The property | What a tool alone does not give you | |
|---|---|---|
| 1 | 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 |
| 2 | 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 |
| 3 | It produces evidence | something that stands on its own, later, without you narrating it. See audit evidence |
| 4 | Exceptions are governed | findings get accepted, and 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.
| Framework | What it actually asks of you |
|---|---|
| SOC 2 | 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 about operation over time, which is why a control that ran inconsistently is worse than one you never claimed |
| ISO 27001 | a management system: risk assessment, controls chosen in response, and evidence of review. Annex A covers secure development and vulnerability management as objectives to meet rather than tools to buy |
| PCI DSS | the prescriptive one. It names requirements around secure development and addressing vulnerabilities in software before release |
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 so is the judgement about them. Where it helps is the mechanics the frameworks care about and engineers find tedious, which are the four properties of a control turned into things a file does.
| Defined | 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 and reviewed the same way |
| Operates consistently | the same descriptor runs in every pipeline, so consistency is a property of the file rather than of somebody remembering |
| Evidenced | every run produces a report you can keep, naming what was scanned, at which revision, by which scanner versions |
| Exceptions governed | each one carries a reason and an expiry, its git history names who wrote it, and the finding stays in the report marked suppressed rather than disappearing |
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. The thresholds, the exceptions and what a run records are in the verdict and the gate.
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.