How to Write a SOC 2 Management Assertion [Example + Template]

  • August 22, 2023
Author

Emily Bonnie

Senior Content Marketing Manager at Secureframe

Reviewer

Fortuna Gyeltsen

Senior Compliance Manager at Secureframe

If you’re preparing for a SOC 2 audit, you know it requires a ton of documentation. One of the most important documents you’ll need to provide your auditor is a management assertion. 

What is a management assertion and what is it for? How do you write one? 

We answer these questions below, then cut to the chase with a sample management assertion and customizable template. 

What is a SOC 2 management assertion?

The management assertion is a letter from company leaders that summarizes the company’s products and services. It provides a series of facts (or “assertions”) by company management about the structure of IT systems, organization controls, and subservice organizations.

Most management assertions are simply the company’s way of saying, “These are our systems, these are the internal controls, and this is how we’ve thought all of it through.” This section can also include management’s assertions about the audit itself, such as the evaluation period and audit scope.

In simple terms, the management assertion tells the auditor how everything is supposed to work so they can evaluate whether that’s how it actually works. The auditor’s final report essentially agrees or disagrees with management’s claims. This is why a management assertion is so important — and why it needs to be as accurate as possible. It’s the foundation for your entire SOC 2 audit. 

For example, if you claim in your management assertion that every employee receives annual cybersecurity awareness training, the auditor must be able to validate that claim by reviewing documentation such as completion certificates. 

The American Institute of Certified Public Accountants (AICPA) outlines three purposes for the management assertion:

  • Determines whether the service organization’s system description is presented in accordance with the criteria
  • Determines whether controls specified in the description were properly designed
  • Addresses whether the controls functioned properly during a Type II report evaluation period

A management assertion may seem like a formality, but it actually speaks to a very important aspect of SOC 2 audits: the auditor and organization management are working together to report on internal controls and their operating effectiveness. By providing a management assertion to the auditor, company leadership is sharing valuable insights into how internal controls are designed and operate within the organization. This makes it easier for auditors to provide a final audit report that is fully informed, objective, and comprehensive. 

How the management assertion fits into a SOC 2 report

The management assertion is an important component of your final SOC 2 report, which guides a reader through the results of your audit.

The main goal of SOC 2 reporting is to assess whether a particular system satisfies the requirements for the relevant Trust Services Criteria (TSC). A SOC 2 report provides detailed information about the audit itself, a description of the system being assessed and related controls, results of testing, and the perspectives of company management.

SOC 2 reports include five sections:

  1. Independent service auditor’s report: The first section of a SOC 2 report is a summary of the audit provided by the auditor. It provides a brief overview of the entire SOC 2 assessment, including the scope, time period, and the auditor's opinion:
    undefinedundefinedundefinedundefined
  2. Management assertion: This section allows company leadership to make claims about the systems and controls that are in scope for the SOC 2 audit.
  3. System description: While the management assertion might provide a brief overview of the system under audit, this section goes into much more detail about the system and control environment. It covers everything from system components and organizational structure to procedures and system incidents.
  4. Tests of controls: Typically the longest section of a SOC 2 report, this is a full list of the auditor’s tests performed during the audit process.
  5. Additional information: Some SOC 2 reports may include an extra section for additional information or management’s response to specific test results.

How to write a SOC 2 management assertion

Because every organization is unique, no two management assertion documents will be the same. While one company might have a concise management assertion that fits on a single page of text, another company’s management assertion might span several pages and include tables and graphs.

That said, Management Assertions are meant to be brief and to the point. They typically include a few introductory paragraphs that outline how the systems under audit are organized and how security controls are designed. 

The management assertion is comprised of three main sections: 

  1. A brief description of the service organization’s system
  2. A claim (or “assertion”) by management that their internal controls were intentionally and thoughtfully designed to achieve the control objectives specified in the system description
  3. An explanation of the criteria used to ensure that controls were applied consistently and effectively throughout the duration of the audit window

 The management assertion is an official document and should be presented on company letterhead.

SOC 2 management assertion example + template

Assertion of [COMPANY NAME] Management Regarding its [SYSTEM NAME] System Throughout the Period [MONTH, DAY, YEAR] to [MONTH, DAY, YEAR]

[COMPANY NAME] management has prepared this description of [COMPANY NAME] (the “service organization”) [SYSTEM NAME] system for the period of [MONTH, DAY, YEAR] to [MONTH, DAY, YEAR] (“description”). The description is based on the AICPA criteria listed in Section 200 of the Description Criteria for a Description of a Service Organization’s System in a SOC 2 Report document. This description is intended to provide report users with information about the [SYSTEM NAME] system that may be useful when assessing risks arising from interactions with [COMPANY NAME] [SYSTEM NAME] system, as well as information about controls that [COMPANY NAME] has designed, implemented, and operated to provide reasonable assurance that its service commitments and system requirements were achieved based on the AICPA Trust Services Criteria relevant to [list applicable trust service criteria (TSCs)] set forth in section 100 of the Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy document

[COMPANY NAME] uses [THIRD PARTY SERVICE], a subservice organization, to provide [SERVICES]; [THIRD PARTY SERVICE], a subservice organization, to provide [SERVICES]; [THIRD PARTY SERVICE], a subservice organization, to provide [SERVICES]. 

This description indicates that complementary subservience organization controls are suitably designed and operating effectively. 

This description indicates that complementary subservice organization controls that are suitably designed and operating effectively are necessary, along with controls at [COMPANY NAME], to achieve [COMPANY NAME]’s service commitments and system requirements based on the applicable Trust Services Criteria. This description presents [COMPANY NAME]’s controls, the applicable Trust Services Criteria, and the types of complementary subservice organization controls assumed in the design of [COMPANY NAME]’s controls. This description does not disclose the actual controls at the subservice organizations.

We confirm, to the best of our knowledge and belief, that: 

a. This description fairly presents [COMPANY NAME]’s [SYSTEM NAME] system, which was designed and implemented throughout the period [MONTH, DAY, YEAR] to [MONTH, DAY, YEAR], in accordance with the description criteria:

  • The description contains the following: 
    1. Types of services provided

    2. System components used to provide the services, which are: 
    -Infrastructure: Physical and hardware system components
    -Software: Programs and operating software of the system
    -People: Personnel who operate and use the system
    -Processes: Automated and manual processes involved in system operations

    3. System scope and boundaries
  • The description does not omit or distort information relevant to the service organization’s system while acknowledging that the description is prepared to meet the common needs of a broad range of users and may not, therefore, include every aspect of the system that each individual user may consider important to his or her own particular needs.

b. The controls stated in this description were suitably designed  throughout the period [MONTH, DAY, YEAR] to [MONTH, DAY, YEAR], to provide reasonable assurance that:

  • [COMPANY NAME]’s service commitments and system requirements would be achieved based on the applicable Trust Services Criteria
  • Its controls operated effectively throughout that period, and 
  • The subservice organization and user entities applied the complementary controls assumed in the design of [COMPANY NAME]’s controls throughout that period

c. The controls stated in the description operated effectively throughout the period [MONTH, DAY, YEAR] to [MONTH, DAY, YEAR], to provide reasonable assurance that:

  • [COMPANY NAME]’s service commitments and system requirements would be achieved based on the applicable Trust Services Criteria if complementary subservice organization controls and complementary user entity controls assumed in the design of [COMPANY NAME]’s controls operated effectively throughout that period

Want a shortcut to writing your own management assertion? Download the Management Assertion template as an editable PDF.

Get expert guidance to prepare for your SOC 2 audit

Getting your SOC 2 report can be a long, tedious process filled with an endless stream of questions. Which report type should you choose? How do you scope your audit? Do your policies and controls satisfy compliance requirements? How do you know you’re fully prepared for an audit?

At Secureframe, we believe everyone should have an expert in their corner to answer those questions and support you at every step of the compliance journey. It’s why we assign every customer a former auditor to help with the entire process — from understanding and implementing control requirements all the way through the audit itself.

Learn more about our team of compliance experts and hear answers to common questions in our Secureframe Expert Insights webinar series.

SOC 1®, SOC 2® and SOC 3® are registered trademarks of the American Institute of Certified Public Accountants in the United States. The AICPA® Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy is copyrighted by the Association of International Certified Professional Accountants. All rights reserved.