The management assertion in SOC 2 and ISAE 3402: what it is and how to write it

Anyone leafing through a SOC 2 or ISAE 3402 report for the first time will find a remarkable document near the front: a statement written not by the auditor, but by the management of the service organization itself. That is the management assertion. Many organizations treat it as a formality the auditor supplies and the board quickly signs. That is a misconception that can lead to unpleasant situations. In this article we explain what the assertion is, why it exists, what it must contain and which mistakes we encounter in practice.

What is a management assertion?

The management assertion is a written statement in which the service organization's management takes a position on three matters. First: that the system description in the report fairly presents the system as it operated during the period. Second: that the controls were suitably designed to achieve the stated control objectives or criteria. Third, for Type II reports only: that the controls operated effectively throughout the entire observation period.

The assertion is therefore not a summary and not a management foreword. It is a formal position the audit builds on. For SOC 2, the requirement stems from the AICPA attestation standards in the United States; for ISAE 3402, from the international standard itself, which requires a management assertion as part of the report.

Why does the assertion exist? The logic of an attestation engagement

A SOC 2 or ISAE 3402 audit is what is known as an attestation engagement. This means the auditor does not draft a description of your system and then opine on it, but expresses an opinion on an assertion made by management. The division of roles is strict: management is responsible for the system description, the controls and the assertion that both are accurate. The auditor tests that assertion and reports whether it is fairly stated in all material respects.

That order is not a paper formality. It determines who is responsible for what. If a system description contains processes that work differently in reality, that is first and foremost a management problem, not an auditor problem. The assertion makes that responsibility explicit and signed. This is also why an auditor cannot write the description and then approve it: they would be reviewing their own work and independence would be gone.

What does it actually contain?

Although the exact wording varies per report, a good assertion always contains the same building blocks. The statement identifies the system and the services the report covers, and the period (Type II) or the point in time (Type I). Management then asserts that the description fairly presents the system, measured against fixed description criteria: for SOC 2 these are the AICPA description criteria, for ISAE 3402 the requirements in the standard itself.

Then comes the core: the assertion that controls were suitably designed to achieve the applicable Trust Services Criteria (SOC 2) or control objectives (ISAE 3402), and for Type II that they operated effectively throughout the period. Finally, the assertion acknowledges the inherent limitations: no system of controls provides absolute assurance, and projecting the conclusion into the future is limited because circumstances change.

If you work with subservice organizations, the assertion must also match the chosen method. Under the carve-out method, management asserts that the description presents the nature of the outsourced services and which complementary controls are assumed at the subservice organization. The complementary user entity controls (CUECs), the controls placed with your customers, must also appear consistently in both description and assertion.

Who signs the assertion?

The assertion is signed by management of the service organization, in practice usually the CEO, COO or the director responsible for the services in scope. Sometimes the CTO or CISO co-signs, because they know the system best. What matters is that the signer is genuinely authorized and informed: someone who can take responsibility on behalf of the organization for the accuracy of the description and the operation of the controls.

What we advise against is delegating the signature to a compliance officer or the external consultant who supported the project. Formally, the board can have the preparation done by others, but the statement itself is a board responsibility. An executive who signs without having read the system description signs for something they do not know. In a dispute with a customer, or worse, an incident that raises liability questions, that is an untenable position.

Common mistakes in practice

The most common mistake is treating the assertion as an afterthought. The document is drafted, circulated and signed in the final week before delivery, without substantive review. Yet the assertion is precisely the moment when management should ask itself: is this picture of our organization accurate, and can we stand behind it?

A second mistake is inconsistency between the assertion, the system description and the actual scope. We see assertions that mention a different period than the report, that name services that have since been phased out, or that describe the carve-out of a subservice organization differently than the system description does. The auditor will catch this in review, but it costs time and does not inspire confidence.

A third mistake: signing while known problems have not been disclosed. The assertion is closely related to the letter of representation management provides at the end of the audit. Anyone who knows a control did not operate for part of the period and does not disclose it signs a statement that is not accurate. Exceptions are not a disaster; an inaccurate assertion is.

Finally, we see organizations copying the assertion verbatim year after year. Scope, services, tooling and subservice organizations change. The assertion must be checked against reality every audit year.

How to get it right

Start on the assertion at the beginning of the engagement, not at the end. Draft a text as soon as the scope and system description are settled, and have the responsible executive review both documents together. Record who signs and why that person is authorized to do so. Shortly before delivery, verify that period, scope, subservice organizations and CUECs match exactly between assertion and description. And discuss internally, before signing, whether any events have occurred that affect the statement: incidents, controls that were not performed for an extended period, changes in the services.

That way the assertion becomes what it should be: not a formality, but the moment when management demonstrably stands behind its own control environment. Want to discuss the setup of your assertion or system description? Feel free to contact us.