SecurityGlobal

SOC 2

Prepare SOC 2 evidence as part of everyday work

Keep control owners, evidence requests and audit follow-ups connected as your service organisation prepares for a SOC 2 examination.

Full name
SOC 2: report on controls at a service organisation relevant to security, availability, processing integrity, confidentiality or privacy
Issued by
AICPA (American Institute of Certified Public Accountants)
Criteria
2017 Trust Services Criteria, with revised points of focus published in 2022
Nature
An attestation report by an independent CPA firm. It is not a certification.
Report types
Type 1: control design at a point in time. Type 2: design and operating effectiveness over a period.
Categories
Security (always included), plus Availability, Processing Integrity, Confidentiality and Privacy as chosen

Overview

What SOC 2 is

SOC 2 is an examination of a service organisation’s controls, carried out by an independent CPA firm under AICPA attestation standards. It ends in a report, not a certificate. Customers read the report to understand how a provider protects the systems and data it handles for them, and many enterprise buyers, particularly in the United States, ask for one during procurement.

The examination is measured against the AICPA Trust Services Criteria. Security, also called the Common Criteria, is always in scope. The organisation chooses whether to add Availability, Processing Integrity, Confidentiality and Privacy, depending on what it promises its customers. The criteria date from 2017. In 2022 the AICPA revised the points of focus, the guidance under each criterion, without changing the criteria themselves.

There are two report types. A Type 1 report gives an opinion on whether controls are suitably designed at a point in time. A Type 2 report also tests whether those controls operated effectively throughout a period, commonly between three and twelve months, so it needs evidence that controls ran consistently across that period. Most customers ask for Type 2.

A SOC 2 report is intended for customers and others with a business need. It describes the system, sets out the controls, and in Type 2 lists the auditor’s tests and any exceptions. A SOC 3 report is a shorter general-use version.

Who it applies to

SOC 2 is relevant to any service organisation that stores, processes or transmits data for its customers, including:

  • SaaS and cloud software providers
  • Data centres, hosting and infrastructure providers
  • Managed IT and managed security service providers
  • Payment, fintech and data processing companies
  • Indian technology and IT services firms selling to US and global enterprises

SOC 2 is not a legal requirement. It is usually driven by customer contracts and procurement.

Structure

How the Trust Services Criteria are organised

Five categories. The Security category, known as the Common Criteria, is always included. CC1 to CC5 follow the COSO 2013 internal control framework, and CC6 to CC9 add criteria for technology and operations.

Security

Common Criteria: governance and oversight (CC1 to CC5)

These five series follow the five components of the COSO internal control framework.

CC1 Control environment
Integrity and ethical values, board oversight, structure and reporting lines, competence, and accountability for internal control.
CC2 Communication and information
Using quality information, and communicating internally and externally about responsibilities and controls.
CC3 Risk assessment
Objectives, identification and analysis of risks including fraud risk, and assessment of changes that could affect controls.
CC4 Monitoring activities
Ongoing and separate evaluations of controls, and communication of deficiencies for corrective action.
CC5 Control activities
Selecting and developing control activities, including general controls over technology, deployed through policies and procedures.
Security

Common Criteria: technology and operations (CC6 to CC9)

CC6 Logical and physical access controls
Access security software and architecture, user registration and authorisation, access reviews and removal, physical access, protection against threats outside system boundaries, transmission security and protection against malicious software.
CC7 System operations
Detecting configuration changes and vulnerabilities, monitoring for anomalies, evaluating security events, responding to incidents and recovering from them.
CC8 Change management
Authorising, designing, testing, approving and implementing changes to infrastructure, data, software and procedures.
CC9 Risk mitigation
Mitigating risks from business disruption, and assessing and managing risks from vendors and business partners.
Optional

Additional categories

Added when the organisation makes commitments to customers in these areas.

Availability (A1)
Capacity management, environmental protections, backup and recovery infrastructure, and testing of recovery plans.
Processing Integrity (PI1)
Complete, valid, accurate, timely and authorised processing, covering inputs, processing, outputs and stored data.
Confidentiality (C1)
Identifying and protecting confidential information, and disposing of it when it is no longer needed.
Privacy (P1 to P8)
Notice, choice and consent, collection, use, retention and disposal, access, disclosure and notification, quality, and monitoring and enforcement of personal information.
Report

What a SOC 2 report contains

Independent service auditor’s report
The CPA firm’s opinion, which may be unqualified or modified.
Management’s assertion
Management’s statement about the system description and controls.
System description
Services, infrastructure, software, people, procedures and data, the boundaries of the system, and any subservice organisations.
Criteria, controls and tests
The criteria in scope and the controls that meet them. In Type 2, the tests performed and their results, including exceptions.
Complementary controls
Controls the provider expects customers to operate, and controls at subservice organisations that are carved out or included.

Implementation roadmap

How to implement it, step by step

A typical route to a first Type 2 report.

  1. 1

    Define the scope

    Decide which services and systems are in scope, which categories beyond Security to include, and which subservice organisations, such as cloud providers, are carved out or included.

    OutputsScope statementCategory selection
  2. 2

    Run a readiness assessment

    Compare current controls with the criteria in scope and record each gap with an owner and a date.

    OutputsReadiness gap list
  3. 3

    Remediate and document

    Close the gaps. Write and approve the policies and procedures, and make sure each control produces evidence as it runs.

    OutputsApproved policiesControl matrix
  4. 4

    Choose a CPA firm and the report type

    Select an independent CPA firm. Some organisations start with a Type 1 report and then move to Type 2. Agree the observation period for Type 2.

    OutputsEngagement letterAudit period
  5. 5

    Operate the controls through the period

    Run every control consistently for the whole period. Reviews that are missed or done late show up as exceptions in a Type 2 report.

    OutputsOperating evidence
  6. 6

    Fieldwork

    The auditor tests controls through inquiry, observation, inspection and reperformance, usually on samples drawn from across the period.

    OutputsEvidence requestsTest results
  7. 7

    Report and management responses

    The CPA firm issues the report. Management can respond to any exceptions within the report.

    OutputsSOC 2 report
  8. 8

    Repeat and bridge

    Most organisations renew each year, so the next period follows on from the last. A bridge letter can cover the gap between a report period and a customer’s request.

    OutputsAnnual cycleBridge letters

Audit and evidence guide

What auditors look for, and the evidence to keep

The CPA firm samples evidence from across the period. Controls must have operated every time they were meant to, not just at the end.

What reviewers look for

  • A system description that matches how the system really works
  • Policies approved, communicated and acknowledged by staff
  • Joiners, movers and leavers handled on time, with access removed promptly
  • Periodic access reviews completed on schedule, with follow-up of findings
  • Changes authorised, tested and approved before release
  • Monitoring and alerting, and incidents handled to closure
  • Vulnerability management and penetration testing
  • Vendor and subservice organisation reviews, including their own SOC reports
  • Backup, recovery and continuity testing, where Availability is in scope
  • A risk assessment performed and reviewed by management

Key timelines

Type 1 reportA point in time
Type 2 observation periodCommonly 3 to 12 months
Report renewalUsually annual
Access reviews, risk assessment, vendor reviewsAs your controls define

Evidence to keep, by area

Examples to guide your evidence library. Your auditor or regulator decides what is sufficient.

Governance

  • Organisation chart
  • Approved policies and acknowledgements
  • Code of conduct
  • Management oversight records

People

  • Background checks
  • Onboarding and offboarding records
  • Security awareness training

Access

  • Access requests and approvals
  • MFA configuration
  • Periodic access reviews
  • Access removal records

Change management

  • Change tickets
  • Testing and approval records
  • Segregation of duties

Operations

  • Monitoring and alert records
  • Incident tickets and post-incident reviews
  • Vulnerability scans
  • Penetration test report

Vendors and risk

  • Vendor risk reviews
  • Subservice organisation SOC reports
  • Risk assessment

Availability

  • Backup logs
  • Restore tests
  • Business continuity and DR tests

Areas that often need attention

  • Controls that did not operate for the whole period, such as a missed quarterly access review
  • Leavers whose access was removed late
  • Changes released without recorded approval
  • Vendor reviews not performed
  • Policies not acknowledged by staff
  • Evidence gathered after the fact instead of as controls ran

How Netra helps

Where each part of the work lives in Netra

Netra loads SOC 2 as requirements, tasks and policies, and keeps the evidence that a Type 2 period needs as the work happens.

Controls that must run all period

Task Engine

Recurring tasks with owners and due dates for reviews, tests and checks, so evidence builds up across the period, not at the end.

Readiness against each criterion

Compliance Centre

Status for each criterion, derived from completed tasks and evidence.

Policies and acknowledgements

Policy Hub

A policy library generated at onboarding, with a score that rises as the work behind each policy is done.

Risk assessment (CC3)

Risk Manager

A risk register with inherent and residual heatmaps, updated as treating tasks are completed.

Vendor and subservice reviews (CC9)

Third-Party Risk

Vendor discovery, assessments through a vendor portal and recorded decisions.

Auditor evidence requests

Audit Centre

Run the examination with evidence already in a tamper-evident vault, and track requests and findings.

Netra supports readiness and evidence. The SOC 2 report is issued by an independent CPA firm after its examination.

Common questions

More questions about Netra

Related frameworks

View all frameworks
Security

ISO 27001:2022 (Requirements)

Build an ISMS your team can run every day

Security

ISO 27001:2022 (Security Controls)

Make security controls visible through completed work

Payments

PCI DSS 4.0.1

Keep payment-security work connected to assessment evidence

See SOC 2 in Netra

See how Netra connects your framework requirements with tasks, evidence and audit follow-up.