SOC 2

SOC 2 is an independent auditor's report on how a service organization protects the data and systems it runs for customers. The framework behind it comes from the American Institute of Certified Public Accountants (AICPA), and the report itself is written by a licensed CPA firm. SOC stands for System and Organization Controls, so despite the similar abbreviation it has no connection to a security operations center.

The yardstick is the Trust Services Criteria, which cover security, availability, processing integrity, confidentiality and privacy. Security is always included, and the organization chooses which of the other four fit the service it sells. The auditor then examines management's description of the system and the controls that support the criteria, and states an opinion.

SOC 2 is not a law and not a certificate. Nobody has to have it, and the auditor does not hand out a pass mark: the report says whether the controls met the criteria and lists any exceptions found. Buyers ask for it because it gives them an outside view of a supplier's data security that a questionnaire cannot.

A SOC 2 report is the end of a process, not the process itself. The audit is short compared with the preparation, and most of the work happens before the auditor arrives:

1. 1

   Set scope and criteria

   Decide which services, systems, and locations are covered, and which categories beyond Security to include.

2. 2

   Run a readiness check

   Compare current controls with the criteria and list the gaps before an auditor finds them.

3. 3

   Operate and record

   Close the gaps, then run the controls in daily work and keep the records: tickets, logs, access reviews, approvals.

4. 4

   Go through the audit

   An independent CPA firm reviews the system description and tests the controls against the criteria.

5. 5

   Receive and share the report

   The report carries the auditor's opinion, is usually shared with customers under NDA, and is renewed on a regular cycle, commonly every year.

Security is mandatory and forms the common criteria: access, change management, risk assessment, monitoring, and incident response. The other four are added only when the service makes promises about them:

SOC 2 asks an organization to show who can reach customer data, how that access is protected and how changes to systems are recorded. Anexet is not an audit tool, but its console keeps several of these records: privileges are set per user group, saving Administrator Console settings can require an additional password, console sessions end automatically after a set time, and the Journal logs administrator actions. Events can also be passed to a SIEM for central monitoring.

1 / 3

• 
• 
• 

A Type I report describes the controls and gives the auditor's opinion on whether they are suitably designed at a single point in time. A Type II report covers a period, typically several months to a year, and adds the auditor's tests of whether the controls actually operated effectively throughout it.

For a buyer, Type II carries more weight: a control that exists is not the same as one that worked every week. Many providers start with Type I to have something to show, then move to Type II. Customers also ask for a bridge letter, a short statement from management about the time between the end of the period and today. It is the provider's own statement, not an audit.

SOC 1 reports on controls that matter for a customer's financial reporting, SOC 2 on the trust services criteria, and SOC 3 is a short general-use summary of the same kind of engagement as SOC 2, without the detailed tests, so it can be published.

ISO/IEC 27001 is the other document buyers ask for. It is a certification of an information security management system (ISMS) by an accredited body, while SOC 2 is an attestation report on controls the organization describes itself. Neither replaces the other, but one body of evidence kept through compliance management can serve both.

Most trouble comes from treating SOC 2 as a badge instead of a way of operating. Careful customers read scope, period, and exceptions before the opinion, because a supplier's gaps become their own compliance risk. The patterns repeat:

• Calling a company “SOC 2 certified” when there is no certificate, only a report
• Scoping so narrowly that the report leaves out the product the customer actually uses
• Trying to rebuild evidence after the period ends, when a Type II test covers the whole period
• Reading only the opinion and skipping the exceptions and the controls the customer is expected to run itself
• Assuming the Privacy criterion proves compliance with a privacy law such as the GDPR

Start from what customers actually ask for, not from the criteria. Choose the service they buy as the scope, begin with Security, and add the other categories only when a customer needs them. Then run a readiness check and give the controls enough time to leave a record before the audit period begins.

Let systems produce the evidence as a by-product of normal work: access lists, change logs, and scheduled security reports, instead of screenshots collected in a rush at the end. A report that is cheap to renew is the one that gets renewed.