SOC 2, without the spreadsheets.
Give US customers the SOC 2 report their procurement team asks for.
What is SOC 2?
SOC 2 is an attestation report issued by an independent CPA firm on how a service organisation protects customer data. It is built on the AICPA Trust Services Criteria: Security is always in scope, and Availability, Confidentiality, Processing Integrity and Privacy are added when relevant.
Who needs it
- B2B SaaS companies selling into the US market
- Vendors whose customers run their own SOC 2 or SOX programmes
- Start-ups whose deals stall at security review
What SOC 2 looks at
Control environment
Governance, ethics, board oversight and accountability — the CC1 criteria that set the tone for everything else.
Logical access
Provisioning, MFA, access reviews and prompt deprovisioning of leavers (CC6).
System operations
Monitoring, vulnerability management and incident response (CC7).
Change management
Code review, approvals and controlled deployment of changes to production (CC8).
How Beviso gets you there
- Continuous evidence across the Type II window, so there is no scramble to reconstruct the period afterwards
- Automated tests on access, MFA, branch protection and offboarding, mapped to the Common Criteria
- Vendor register and security questionnaires for the CC9 vendor-management criteria
- Auditor portal so your CPA firm can sample evidence without a shared drive
15 SOC 2 controls, ready on day one
These controls are loaded when you enable SOC 2, each with the tools that can supply its evidence automatically. You can add your own controls alongside them.
CC6.1
Logical and Physical Access Controls
The entity implements logical access security software, infrastructure, and architectures over protected information assets.
Evidence from
- Okta
- GitHub
- Google Workspace
- Microsoft Azure
- AWS
- Cloudflare
- HashiCorp Vault
CC6.2
User Registration and Deprovisioning
Prior to issuing system credentials and granting access, the entity registers and authorizes new internal users.
Evidence from
- Okta
- Google Workspace
- Microsoft Azure
- JumpCloud
- GitHub
- OneLogin
- Auth0
CC6.3
Role-Based Access and Least Privilege
The entity authorizes access to information assets on a need-to-know basis.
Evidence from
- Okta
- AWS
- GitHub
- Microsoft Azure
- HashiCorp Vault
- Google Workspace
CC6.6
Controls to Prevent Threats from External Sources
Logical access security measures are implemented to protect against threats from sources outside its system boundaries.
Evidence from
- Cloudflare
- AWS
- DigitalOcean
- Hetzner
- CrowdStrike
- SentinelOne
CC6.7
Transmission of Data
Restrictions are placed on the transmission of information.
Evidence from
- Cloudflare
- HashiCorp Vault
- Doppler
- 1Password
- Bitwarden
CC6.8
Malicious Software Prevention
Controls are implemented to prevent or detect and act upon the introduction of unauthorized or malicious software.
Evidence from
- CrowdStrike
- SentinelOne
- Microsoft Defender
- Jamf
- Kandji
CC7.1
Detection and Monitoring of New Vulnerabilities
New vulnerabilities are identified and the risk is evaluated and addressed on a timely basis.
Evidence from
- Snyk
- Wiz
- Qualys
- Rapid7
- Lacework
- AWS
- Detectify
- SonarCloud
- GitHub
CC7.2
Monitoring System Components
The entity monitors system components for anomalies that are indicative of malicious acts, natural disasters, and errors.
Evidence from
- Datadog
- Splunk
- Grafana
- New Relic
- Dynatrace
- PagerDuty
- AWS
CC7.3
Security Event Evaluation
Detected security events are evaluated to determine whether they represent security incidents.
Evidence from
- PagerDuty
- ServiceNow
- CrowdStrike
- SentinelOne
- AWS
- Lacework
- Datadog
CC7.4
Security Incident Response
The entity responds to identified security incidents by executing defined incident response procedures.
Evidence from
- PagerDuty
- ServiceNow
- Jira
CC8.1
Change Management Process
The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure.
Evidence from
- GitHub
- GitLab
- Jira
- ServiceNow
- Azure DevOps
CC9.1
Risk Mitigation Activities
The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.
Evidence from
- PagerDuty
- ServiceNow
- Datadog
- Grafana
CC9.2
Vendor Risk Management
The entity assesses and manages risks associated with vendors and business partners.
Evidence from
- Ironclad
- DocuSign
CC1.4
Commitment to Competence
The entity demonstrates a commitment to attract, develop, and retain competent individuals.
Evidence from
- BambooHR
- HiBob
- Personio
- Workday
- Rippling
- Deel
CC2.1
COSO Principle 13 — Information Quality
The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
Evidence from
- Datadog
- Splunk
- HashiCorp Vault
- 1Password
- Salesforce
- Bitwarden
SOC 2 questions
- Should we start with Type I or Type II?
- Many teams do a Type I first to unblock deals, then start the Type II observation window. Beviso collects evidence continuously from day one, so the same work counts towards both.
- Is SOC 2 relevant for a European company?
- If you sell to US customers, usually yes. Beviso maps overlapping controls to ISO 27001, so European teams can run both from one set of evidence.
- Which Trust Services Criteria should we include?
- Security is mandatory. Add Availability or Confidentiality when customers rely on your uptime or send you confidential data. Privacy is less common and overlaps heavily with GDPR.
Often run alongside SOC 2
Start your SOC 2 programme today.
Free while Beviso is in beta. No credit card required.
Get started free