Prepare for your SOC 2 report in one system.
SOC 2 is the AICPA attestation many enterprise buyers ask for. In Alvor you work each Trust Services Criterion as a control with an owner, an applicability decision and evidence, automated checks test your cloud, identity and source-control settings, and audit findings become tasks or risks.
SOC 2 overview
The standard enterprise buyers trust
33
Common criteria in the Security category
5
Trust Services Criteria
2
Report types: Type I and Type II
SOC 2 is the de facto security standard for SaaS companies selling to enterprise customers. Based on the AICPA's Trust Services Criteria, it evaluates your controls across five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. A Type II report covers the design and operating effectiveness of controls over a 3–12 month observation period.
Domain coverage
Five Trust Services Criteria
SOC 2 evaluates controls across five categories. Security (CC series) is required; the others are optional based on your service commitments.
Security (CC Series)
The foundational criterion, required for every SOC 2 report. Covers access control, system operations, change management, risk mitigation, and logical/physical access across 33 common criteria.
Availability
Controls ensuring your system is operational and accessible as committed in SLAs. Covers performance monitoring, disaster recovery, incident response, and capacity planning.
Processing Integrity
Ensures system processing is complete, valid, accurate, timely, and authorized. Covers data quality checks, error handling, and processing monitoring.
Confidentiality
Controls for protecting confidential information: encryption, access restrictions, secure disposal, and classification. Covers data throughout its lifecycle.
Privacy
Controls for personal information collection, use, retention, and disposal aligned to the AICPA's privacy criteria and regulations like GDPR and CCPA.
Common Criteria (CC1–CC9)
Nine series: control environment, communication and information, risk assessment, monitoring activities, control activities, logical and physical access, system operations, change management, and risk mitigation.
Common challenges
Where SOC 2 preparation slows down, and how Alvor helps
The problem
Your biggest prospect just sent a security questionnaire and you have nothing to show them
How Alvor helps
Open any control's Evidence tab and the files, owner and expiry date are there to share. The controls list exports to CSV.
The problem
Spending weeks collecting screenshots, policy docs, and config exports from a dozen different tools
How Alvor helps
Automated checks test AWS, Okta, Microsoft Entra ID, GitHub and GitLab settings on a schedule and set the status of the controls they prove. Other evidence is uploaded once and linked to every criterion it supports.
The problem
Nobody is sure which controls the auditor will test or who owns them
How Alvor helps
Every criterion has a named owner and an applicability decision, and policies link to the controls they cover, so the gaps show before the auditor arrives.
The problem
The audit observation period hasn't started because you still can't prove controls are operating effectively
How Alvor helps
Bound checks run on their schedule and write dated findings, and a posture snapshot is recorded every day, so the observation period has a dated record behind it.
What you get
SOC 2 readiness in one record
SOC 2 in the framework library
SOC 2 installs with its five Trust Services Categories, and the criteria load from your licensed copy. Each criterion then works like any other control: an owner, an applicability decision, evidence with an expiry date, and a status set by an assessment, an automated check or a recorded override.
Automated control checks
Connect AWS, Okta, Microsoft Entra ID, GitHub or GitLab and bind checks such as root MFA, admin MFA or branch protection to the controls they prove. Each check runs hourly, every four hours, daily or weekly, writes a finding for every failing resource and sets the control's status.
Evidence requests inside an audit
Scope an audit to the criteria in play. Starting it creates an assessment for each control and notifies its owner. Inside the audit, request evidence from control owners with a due date and track each request until it is assessed.
A dated record for Type II
A Type II report covers a period, so the record behind it has to be dated. Checks write dated findings on their schedule, a posture snapshot is recorded every day, and each control's review cadence shows when it is due again.
Evidence the auditor can open
Each control's Evidence tab holds the files and links behind it, with tags, a description and a valid-until date. Evidence uploaded once is linked to every control it supports, and the controls list exports to CSV.
Audit readiness and findings
The dashboard shows audit readiness, open findings and evidence health, and the Audit Readiness and Findings & Remediation reports show what is left and who owns it.
Frequently asked
Common questions about SOC 2
Answers to the questions security and compliance teams ask when pursuing their first SOC 2 report or renewing an existing one.
A SOC 2 Type I report attests to the design of controls at a single point in time. A SOC 2 Type II report attests to both the design and operating effectiveness of controls over an observation period, typically 3 to 12 months. Most enterprise buyers require Type II; Type I is often used as an interim milestone on the way to Type II.
Get started
See how Alvor works for your role
Whether you lead security, run IT, manage compliance, or sit in the C-suite - we'll show you your view.