What is SOC 2? A plain-English guide for career starters (it's a report, not a certificate)

SOC 2 is an attestation report, not a certification. An independent CPA firm examines a service organisation’s controls under standards set by the AICPA (the American Institute of Certified Public Accountants) and issues a report giving its opinion on those controls. Nobody is “SOC 2 certified” in the way a company can be ISO 27001 certified; a company has a SOC 2 report, for a defined system and, usually, a defined period.

That distinction sounds pedantic, but it’s the first thing a GRC interviewer will listen for. This guide explains what SOC 2 is, how Type I and Type II differ, what the Trust Services Criteria are, what’s actually inside a report, and which jobs work with SOC 2 every day.

First, which “SOC” are we talking about?

Beginners trip on this constantly. In cybersecurity, “SOC” has two unrelated meanings:

A “SOC 2 analyst” advert is a compliance job, not a monitoring job. Read the description before applying.

What is SOC 2, exactly?

The AICPA describes System and Organization Controls as a suite of services CPAs provide in connection with an organisation’s controls (AICPA SOC suite). Within that suite:

• SOC 1 reports on controls relevant to a client’s financial reporting. A payroll processor is the classic example.
• SOC 2 reports on controls relevant to security, availability, processing integrity, confidentiality or privacy. This is the one technology and SaaS companies are asked for.
• SOC 3 covers the same ground as SOC 2 but is a short, general-use report that can be published, without the detailed testing.

SOC 2 is an attestation engagement: the CPA firm examines the organisation’s description of its system and its controls, then gives an opinion. The full report is restricted-use. Customers usually get it under a non-disclosure agreement, not from a public website.

Why SOC 2 matters outside the US

SOC 2 is an American framework, but it travels with American customers. A Lagos fintech selling an API to a US company, or a Nairobi SaaS start-up signing a US enterprise client, will often be asked for a SOC 2 report during vendor due diligence. That’s why the skill set is useful far beyond the US, even though only a licensed CPA firm can issue the report.

Why isn’t SOC 2 a certification?

Because of how it works:

• Certification (for example ISO/IEC 27001) means an accredited certification body audits you against a standard and, if you meet it, issues a certificate that’s valid for a set term, with surveillance audits in between.
• SOC 2 attestation means a CPA firm examines your controls against criteria and issues an opinion in a report. There’s no pass/fail certificate and no logo scheme in the ISO sense. The report describes what was tested, and, for Type II, what happened when it was tested, including any exceptions.

So when a job advert or a client says “SOC 2 certified”, they almost always mean “has a SOC 2 report”. Use the right term in interviews and documents. If you want the ISO comparison in depth, see ISO 27001 explained for beginners.

SOC 2 Type I vs Type II

A worked example with a fictional company, Acme Fintech Ltd:

• Type I, as of 1 March: the auditor confirms Acme has a documented access-review control and that it exists in practice: there’s a procedure, and an example review was performed.
• Type II, 1 March to 31 August: the auditor samples quarterly access reviews across the six months, checks each one was completed, approved and acted on, and reports any that weren’t.

Many organisations start with a Type I to get something in front of customers, then move to a Type II.

What are the Trust Services Criteria?

SOC 2 controls are evaluated against the AICPA’s Trust Services Criteria (the 2017 criteria, with points of focus revised in 2022). There are five categories:

1. Security. Required in every SOC 2. Protection of information and systems against unauthorised access, disclosure and damage. This is where the Common Criteria live.
2. Availability. The system is available for operation and use as committed or agreed.
3. Processing integrity. System processing is complete, valid, accurate, timely and authorised.
4. Confidentiality. Information designated as confidential is protected as committed or agreed.
5. Privacy. Personal information is collected, used, retained, disclosed and disposed of in line with the organisation’s commitments.

The organisation chooses which categories beyond Security are in scope, usually based on what its customers care about. A cloud hosting provider will almost certainly include Availability; a payroll processor may add Processing Integrity.

The Common Criteria, in one table

The Security category is organised into common criteria series. Career starters should recognise them by name:

CC1 to CC5 follow the structure of the COSO internal control framework, which is why accountants find SOC 2 familiar.

What’s inside a SOC 2 report?

A Type II report typically has these sections:

1. The service auditor’s report (the opinion). The CPA firm’s conclusion. An unmodified opinion is the clean result; a qualified opinion means something significant didn’t meet the criteria.
2. Management’s assertion. The organisation’s own statement that its description is fair and its controls are suitably designed and operating.
3. The system description. Services in scope, infrastructure, software, people, data, processes, subservice organisations (for example, the cloud provider) and complementary user entity controls (the things the customer must do for the controls to work).
4. Criteria, controls, tests and results. Each control mapped to the criteria, how the auditor tested it, and the result, including exceptions.

Here’s what an exception looks like in practice (fictional):

Control CC6.2-03: Access for leavers is removed within one business day of termination. Test: Inspected a sample of 25 leavers during the period and compared termination date with account deactivation date. Result: Exception noted. For 2 of 25 leavers, access was removed after five business days.

An exception doesn’t automatically mean a qualified opinion. Reading exceptions, judging their significance and asking the vendor what they did about them is a core GRC skill.

How does a company get a SOC 2 report?

A simplified journey, as you’d see it from inside a compliance team:

1. Scope. Decide the system, the Trust Services Criteria categories and Type I or II.
2. Readiness assessment. Map existing controls to the criteria; identify gaps. Often done internally or by a consultant, separately from the auditor.
3. Remediate. Write missing policies, switch on MFA, formalise access reviews, set up change management, collect evidence.
4. Observation period (Type II). Controls run as designed, and evidence is retained.
5. Examination. The CPA firm requests evidence, samples it, interviews control owners and tests.
6. Report issued. Then the cycle repeats, usually annually. Between reports, companies often provide customers with a bridge letter covering the gap.

Evidence is the currency. Typical requests include an export of all users with production access, screenshots of MFA settings, a sample of pull requests showing approvals, the incident register, signed policy acknowledgements and vendor reviews.

SOC 2 jobs: who works with it?

Here’s who does SOC 2 work day to day. SOC 2 work sits on both sides of the table:

Inside the company being examined

• GRC or compliance analyst: maintains the control set, collects evidence, coordinates with the auditor, tracks remediation. This is the most common entry point; see what a GRC analyst does.
• Security engineer or IT administrator: owns technical controls such as MFA, logging, backups and access reviews.
• Control owners across the business: HR (onboarding and leavers), engineering (change management), finance (vendor contracts).

At the CPA firm

• IT audit or risk assurance associate: tests controls, samples evidence and drafts findings. The opinion itself is signed by the licensed CPA firm.

On the customer side

• Third-party risk analyst: reads vendors' SOC 2 reports, checks scope, exceptions and complementary user entity controls, and decides whether the risk is acceptable.

A fictional but realistic job description excerpt for an entry-level role:

Compliance Analyst (SOC 2 and ISO 27001), Acme Fintech Ltd. Maintain our control library; collect and organise audit evidence; run quarterly access reviews with system owners; track remediation of audit exceptions; review vendor SOC 2 reports and summarise risks; support policy updates.

Notice what’s missing: you don’t need to be a CPA to do most of these jobs. You need to understand controls, evidence and risk, and to write clearly.

How SOC 2 relates to other frameworks

SOC 2 rarely exists alone. Organisations often map one set of controls to several frameworks:

• ISO/IEC 27001: a certifiable management system standard with Annex A controls. Lots of overlap with SOC 2’s Security category.
• NIST CSF 2.0: a voluntary framework for organising a security programme around six functions. Useful as a common language; see NIST CSF 2.0 explained.
• Nigeria’s data protection regime: if personal data of people in Nigeria is involved, the Nigeria Data Protection Act and guidance from the Nigeria Data Protection Commission apply regardless of any SOC 2 report. SOC 2’s Privacy category doesn’t replace legal obligations.

The AICPA publishes mappings between the Trust Services Criteria and other frameworks, which is a good place to practise control mapping.

What a career starter can practise this week

1. Download the Trust Services Criteria from the AICPA link above and read the Security category’s CC6 series in full.
2. Build a mini control matrix for a fictional ten-person SaaS company: ten controls, each with an owner, frequency, criteria mapping and the evidence you’d collect.
3. Write one exception like the example above and a one-paragraph management response.
4. Practise explaining “SOC 2 is a report, not a certification” in two sentences. You’ll use it in interviews.