Because a QSA reviews and reports on the evidence presented, while the organisation owns the controls, the operating processes, and the future changes that affect risk. If data handling is flawed, or if staff later mishandle sensitive information, liability usually stays with the organisation. Assurance is limited, responsibility is operational.
Why QSA assurance does not transfer liability
A QSA report is an assessment of what was presented at a point in time, not a transfer of ownership for the environment. The organisation still operates the systems, sets the procedures, trains the people, and approves changes that can create or expose a breach. If the controls were weak, incomplete, or later undermined, responsibility remains with the organisation.
Compliance reports are useful evidence, but they are not a warranty that data handling is safe in practice. Organisations can be fully responsible for failures that occur after the assessment, especially when real operations diverge from the control design or when staff bypass the intended process.
What the report actually covers, and what it does not
A compliance report typically evaluates whether the auditor found enough evidence to support the stated outcome against a defined scope. That scope matters: it may exclude business units, systems, time periods, or operational behaviours that still carry risk. For that reason, a clean report should be read as “assessed against this scope,” not “all security obligations are now resolved.”
The practical limitation is that controls are living things. Access models drift, logging coverage degrades, secrets spread, and handling practices change after the assessment. When the operating reality changes, the earlier report loses explanatory power for the new condition unless the organisation keeps validating the control environment.
In payment environments, that distinction is reinforced by PCI DSS v4.0 expectations around restricting access by business need and managing system and application accounts appropriately, which is why evidence of control design is never the same thing as continuous operational control. The same logic appears in broader control catalogues such as NIST SP 800-53 Rev 5 Security and Privacy Controls.
Why breach accountability stays with the organisation
Responsibility stays with the organisation because it owns the decision to implement, maintain, monitor, and change the control environment. A QSA can test evidence, but only the organisation can ensure the controls continue to match the real process, real data flows, and real users. If staff mishandle sensitive information, or if an approved process is later bypassed, the failure is operational rather than advisory.
This is also why governance, not just audit, matters. Strong compliance posture requires SOC 2 Trust Services Criteria style discipline around control operation, but the organisation still has to prove that its daily behaviour matches the stated control intent. If the evidence was accurate yesterday and the process fails today, yesterday's report does not absorb today's breach.
Risk and Threat Considerations
Compliance assurance can create false confidence when organisations treat an external report as a substitute for control ownership. The real risk is control drift, where the assessed state looks acceptable but the live environment has changed enough to expose data, privilege paths, or handling failures.
Failure mechanism: The organisation assumes the report covers the current operating state, while actual access patterns, data handling, or privileged workflows diverge after the review. That gap is where breaches, regulatory findings, and accountability disputes usually emerge.
Impact: Exposure can persist even with a valid report on file, because the organisation remains the party responsible for the breach, the remediation, and the evidence trail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Breach accountability depends on whether control operation is reviewed and acted on. |
| Recommendation — Review audit evidence continuously and escalate when live operations diverge from the assessed control state. | ||
| ISO/IEC 27001:2022 | A.5.36 — Compliance with policies, rules and standards for information security | A compliance report does not replace the organisation's duty to operate controls as intended. |
| Recommendation — Maintain evidence that policies and controls are actually enforced in day-to-day operations. | ||
| SOC 2 (AICPA) | CC4.1 — Control Activities | The question centers on assurance versus operational responsibility after a compliance report. |
| Recommendation — Demonstrate that control activities remain effective after the report date. | ||
Practitioner Guidance
What to verify: Treat the report as evidence of assessed scope, not as proof of ongoing control performance. Verify whether the breached process, team, system, or data flow was actually inside the reviewed boundary and whether the control still operated as tested when the incident occurred.
Common mistake: The most expensive error is using compliance status to answer an incident question. If the issue is mishandling, stale access, or a process change after the review, the right question is whether operational controls still matched the documented design at the time of loss.
Practitioner takeaway: A QSA report can support assurance, but it never displaces the organisation's duty to run the control environment correctly; liability follows operational ownership, not audit participation.
Related resources from NHI Mgmt Group
- Why do non-human identities create compliance risk even when policies exist?
- Why do data breaches stay costly even after organisations invest in security tools?
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities for SOC 2 compliance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
