What the SOC 2 report contains
A SOC 2 report has a fixed structure. It starts with the audit firm's opinion. This is followed by management's assertion from the audited company that the system description is accurate and the controls are suitably designed and, for Type II, that they operated effectively. The core is the system description: services, infrastructure, software, people, procedures, data, subservice organisations involved and the relevant controls. The AICPA sets its own description criteria for this.
For Type II, a table follows that maps each criterion to the controls, describes the auditor's tests and states the result. Deviations, known as exceptions, are also listed there, for example if in a sample a leaver was not blocked in time. Individual exceptions do not automatically lead to a qualified opinion, but customers do read them.
Two further sections are important for your customers. Complementary user entity controls describe what the customer must do themselves, such as managing their own access. Complementary subservice organisation controls describe what you rely on at your data centre or cloud provider. These are either included in the examination or carved out. You must monitor carved-out service providers yourself, typically via their own reports.
Costs and internal effort
SOC 2 has two cost blocks. The Sightadel licence is charged monthly per edition, with discounts for multiple frameworks and advance payment. You can find all prices and a calculator on our pricing page.
The audit firm invoices independently. Its fee depends mainly on four factors: the number of criteria beyond Security, the report type, the length of the observation period and the complexity of the system with sites, platforms and subservice organisations involved. Obtain several quotes and clarify in advance whether a readiness assessment is included and how many samples the firm intends to take.
The biggest item is usually internal time. Someone has to write policies, introduce controls, produce evidence on schedule and answer the auditors' questions. In growing software companies, this often falls to one person from engineering or operations who also looks after the product. A clear plan with recurring tasks prevents evidence being recreated in the last month of the observation period. That does not work anyway, because the auditor recognises evidence created after the fact by its date.
Choosing the right criteria
Security is always included. You choose the other four categories according to your service and your customers' expectations. Availability fits if customers depend on committed uptime and you can evidence recovery and capacity. Confidentiality fits if you process your customers' confidential business information and make commitments about its protection and deletion. Processing Integrity makes sense if the accuracy of your processing is itself the product, for example for billing or payments. Privacy relates to personal data and is demanding in content.
More criteria mean more audit effort and more surface for exceptions. A lean first report with Security and, where appropriate, Availability is often the smarter start. You can expand in the next audit cycle. Ask your most important customers which criteria they expect before you define the scope.
In Sightadel, you choose the scope at the start. Only the relevant controls appear, and the reasoning for your choice is recorded for the auditor. The basis is the 2017 Trust Services Criteria with the revised points of focus from 2022.
Sustaining the Type II observation period
Type II examines whether controls actually operated over a period. The auditor takes samples from the entire period: individual new hires and leavers, changes to the production system, quarterly access reviews, security incidents, vulnerability scans, training records. For every sample, dated evidence must exist.
Most exceptions do not arise from missing controls, but from gaps in the rhythm. The third-quarter access review fell in the holiday season, the new colleague's training was forgotten, a hotfix went live without approval. Every such gap shows up in the report.
It helps to set up all recurring controls as cycles before the period starts, with an owner, a deputy and a due date. Sightadel reminds you before every date and shows on the dashboard which evidence is missing. If the observation period runs to the end of the year, the next one starts directly afterwards so that the follow-up report connects seamlessly. For the time between the end of the report period and the new report, many companies issue a bridge letter to their customers.
Also plan buffers for staff changes. If the person operating a control leaves the company in the middle of the period, the deputy must take over seamlessly. That is why you should define a deputy alongside the owner for every recurring control.
What documentation the auditor wants to see
To start, you need a set of policies and procedures: information security, access control, change management, incident response, backup and recovery, risk assessment, vendor management, code of conduct, HR processes for joiners and leavers, encryption and retention. On top of that come an organisation chart, the system description and an overview of the subservice organisations involved.
More important than the policies is the evidence that they are lived. Typical examples are approvals in the ticketing system, records of access reviews, extracts from the HR system, reports from vulnerability scans and monitoring, results of restore tests, training records, signed confidentiality agreements, the risk register and the assessment of vendors including their reports.
In Sightadel, every piece of evidence is attached to the control it proves, with a date and an expiry date. Evidence from ISO 27001 can be assigned to the same SOC 2 control without filing it twice. The auditors get their own access, see answers, comments and history and can comment, but never delete, instead of receiving folders by email.
A note on the system description: it is written by you, not by the auditor. Start early, because it forces you to clarify which components, sites and service providers really belong to the system. Unclear boundaries are a frequent cause of follow-up questions and delays.
SOC 2 alongside ISO 27001 and C5
For providers with customers on both sides of the Atlantic, the question arises whether one attestation is enough. The answer is usually: largely yes in content, no in form. European customers and tenders ask for ISO 27001, German cloud customers and public sector clients increasingly for BSI C5, US customers for SOC 2.
The difference lies less in the controls than in the type of audit. ISO 27001 assesses a management system and ends with a certificate from an accredited body. SOC 2 and C5 are examinations by independent auditors which, for Type II, confirm effectiveness over a period and deliver a detailed report.
If you maintain the controls properly once and assign every piece of evidence to all matching requirements, you can base several audits on the same foundation. Some audit firms offer combined audits in which samples are used for several reports. Whether that suits your case is something to clarify with the firm. We deliberately do not give a percentage for the overlap; it depends on the scope.