SOC 2 readiness

A SOC 2 report is an attestation, not a certificate: an independent CPA firm examines your controls against the AICPA Trust Services Criteria and issues a Type I report (controls are suitably designed at a point in time) or a Type II report (controls operated effectively over a period, typically 3 to 12 months).

Any service organisation whose customers need assurance about how it protects their data — in practice most B2B SaaS companies selling to mid-size and enterprise customers. You choose the categories in scope: Security (the Common Criteria) is always included; Availability, Processing Integrity, Confidentiality and Privacy are optional.

• Control environment and governance (CC1–CC5). Board or leadership oversight, defined responsibilities, risk assessment, monitoring of controls and documented policies.
• Logical and physical access (CC6). Least-privilege access, authentication, encryption of data at rest and in transit, protection against threats from outside the system boundary.
• System operations (CC7). Vulnerability and configuration monitoring, anomaly detection, incident response and recovery.
• Change management (CC8). Changes to infrastructure and software are authorised, designed, developed, tested and approved before release.
• Risk mitigation (CC9). Business disruption planning and management of vendor and business-partner risk.
• Optional categories. Availability (A1), Processing Integrity (PI1), Confidentiality (C1) and Privacy (P1–P8) add criteria when you put them in scope.

12 RuleFix rules run when SOC 2 is selected on a project. 6 of the framework's controls have at least one rule mapped to them. The table is generated from the rule catalogue, so it always matches what the scanner runs.

A mapping means the rule checks part of that control in application code or configuration. Passing every rule does not satisfy a control: each one also needs process, people and infrastructure work that no code scanner can see.

Most of an audit is organisational. You need these in place regardless of what any scan finds:

• Governance and HR. Board oversight, org chart, background checks, code of conduct, security awareness training and disciplinary process (CC1, CC2).
• Risk and vendor management. The risk register, risk assessments and due diligence on vendors and subprocessors (CC3, CC9).
• Access administration. Joiner-mover-leaver process, quarterly access reviews and MFA on your own SaaS and cloud consoles.
• Operations. Backups and restore tests, monitoring and on-call, incident response exercises and post-mortems.
• Change approval. Pull-request review and approval rules, branch protection and deployment approvals — RuleFix supplies test evidence for a change, not the approval.
• Physical security. Usually inherited from your cloud provider's own SOC 2 report; you still review it.

Select SOC 2 on each project in scope. Every scan then records findings with stable fingerprints. An issue becomes Fixed when a complete scan no longer finds it, when your agent resolves it with a confirming re-scan, or when a person marks it — and every status change is written to the audit log with who made it. The evidence report (print to PDF or JSON) collects the latest scan, score history, open and resolved findings and triage decisions per framework.

• For Type II, the auditor samples across the whole period. Run RuleFix on every change (from your AI agent over MCP, or repository scans) so the scan history covers the period without gaps.
• Export the project evidence report (print to PDF or JSON) at the end of each month and file it in your evidence folder; the score history and resolved findings show the control operating, not just existing.
• Use the control mappings below to tag findings to CC6.1, CC6.7, CC7.1 and CC8.1 in your GRC tool.
• Ignored findings and in-code `rulefix-ignore` comments carry a reason and show in the audit log or diff — auditors look for documented risk acceptance, so always write the reason.

• Write the system description and decide the categories in scope (Security plus any optional ones).
• Pick an auditor and decide between Type I first or going straight to a Type II observation period.
• Publish the core policies: information security, access control, change management, incident response, vendor management, data retention.
• Turn on RuleFix with SOC 2 selected for every in-scope repository; fix all high findings and agree a fix timeline for medium and low.
• Enforce branch protection and pull-request review on in-scope repositories.
• Enable MFA everywhere, run a first access review and record it.
• Build a vendor inventory with each vendor's own SOC 2 or ISO 27001 report.
• Test a backup restore and run an incident-response tabletop; keep the notes.
• Start the observation period and export RuleFix evidence reports monthly.