Assertion
Also known as: Management representations, Control claims, Representations
A claim made by management or a system owner stating that specific controls are implemented and functioning correctly. It serves as the formal basis for an auditor's testing process. In frameworks like SOC 2, these claims describe how a company meets security and availability criteria.
Why it matters
If these claims are false, auditors may rely on non-existent controls, leading to an incorrect "clean" report that masks critical vulnerabilities. A failure here results in a qualified opinion or a material exception in the final audit report. This can lead to loss of customer trust and breach of contractual SLAs with enterprise clients. Ultimately, the CISO or Head of Compliance is held accountable for the accuracy of these statements.
In practice
During the planning phase, the auditor reviews the management's description of the system to identify these claims. The control owner then provides evidence—such as screenshots of firewall rules or user access logs—to prove the claim is true. This process produces a testing matrix where each assertion is mapped to specific evidence and an outcome (Pass/Fail). In first-year engagements, auditors spend more time validating that the statements are logically sound and comprehensive. Repeat engagements focus on "roll-forward" testing to ensure the claims remain true over a new period.
Worked example
CloudSecure Inc. asserted in their 2023 SOC 2 report that all employee access is revoked within 24 hours of termination. The auditor requested a list of employees who left between January and June, along with their Active Directory account disablement timestamps. Upon review, the auditor found three users whose accounts remained active for five days post-termination. This discrepancy proved the claim was inaccurate. Consequently, the final report included a "qualified" opinion regarding the access control domain.
Common mistakes
- Writing claims that are too vague, such as "we keep data secure," which cannot be objectively tested or verified.
- Confusing a claim of fact with a policy; one states that something is happening, while the other is a rule for behavior.
- Assuming evidence from previous years supports current statements without updating documentation to reflect new system changes.
- Failing to align claims across different frameworks (e.g., ISO 27001 vs SOC 2), creating contradictory statements about the same process.
Frequently asked questions
What is the difference between an assertion and a control?
A control is the actual mechanism used to mitigate risk, such as requiring MFA for logins. An assertion is the formal claim that this specific control exists and works as intended across the organization.
When are assertions formally documented in a security audit?
They are typically documented at the start of the engagement within the "Management Assertion" letter or the system description document. This sets the scope for what the auditor will verify during the testing phase.
How do I write a testable assertion for data protection?
Use specific, measurable language that defines who, what, and when. Instead of saying "we encrypt data," state "all PII stored in our AWS S3 buckets is encrypted at rest using AES-256."
What evidence is typically required to support a compliance assertion?
Evidence varies by claim but usually includes system configurations, signed policy acknowledgments, or timestamps from logs. The auditor looks for artifacts that provide objective proof of the stated behavior.
Can an auditor change a management assertion during an audit?
No; auditors test existing claims rather than writing them for the client. If a claim is found to be inaccurate, the auditor reports the failure or asks management to revise their statement before finalization.
More terms
Chain of custody · COSO framework · Materiality · Audit evidence · Segregation of duties · IT general controls · Data Protection Impact Assessment · Residual risk