How to Meet SOC 2 Security Requirements in Practice

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• Security (CC1 - CC9) is required in every SOC 2 report; all other criteria are optional.
• The biggest audit effort is on CC6 (Logical & Physical Access Controls) and CC7 (System Operations).
• Type II audits need continuous, timestamped evidence covering the full 6 - 12 month observation window.
• Implement MFA, RBAC with regular reviews, AES - 256 at rest, TLS 1.2/1.3, centralized logging, weekly vulnerability scans, a documented IRP and vendor risk process to satisfy the Security criterion.

What is the Security trust services criterion in SOC 2?

The Security criterion, also called the Common Criteria, must be present in every SOC 2 audit. It consists of nine sub - criteria (CC1 - CC9) that together contain 33 points of focus that auditors evaluate for design and operating effectiveness. The other SOC 2 categories (Availability, Confidentiality, Processing Integrity, Privacy) are only added when a service - organization’s commitments require them.

Which sub - criteria consume the most auditor time?

Auditors spend the most time on CC6 (Logical & Physical Access Controls) and CC7 (System Operations). CC6 has eight sub - criteria covering network perimeter, identity provisioning, role - based access, physical facility security, credential protection, third - party access, data - in - transit security and malware prevention. CC7 has five sub - criteria that address vulnerability detection, anomaly monitoring, event evaluation, incident response and recovery.

How should I implement multi - factor authentication to satisfy SOC 2?

Deploy MFA on every privileged and production account. Use a time - based one - time password (TOTP) or hardware token that integrates with your identity provider (Okta, Azure AD, etc.). Enforce MFA for admin console logins, API keys and any remote access method. Document the MFA policy, include screenshots of the configuration, and retain logs of successful and failed MFA attempts for the entire audit period.

What does role - based access control need to look like?

Create RBAC roles that reflect the principle of least privilege. Assign each user only the permissions required for their job function. Automate provisioning and de - provisioning via SCIM or scripted workflows so that when an employee leaves, access is revoked the same day. Generate quarterly access - review tickets that are signed - off by a manager; keep the ticket history as evidence.

How can I prove encryption is in place?

Encrypt data at rest with AES - 256 using cloud - native key management services (AWS KMS, Azure Key Vault, etc.). Encrypt data in transit with TLS 1.2 or TLS 1.3; disable older protocols and weak cipher suites. Maintain key - rotation logs that show each key creation and rotation date. Export configuration snapshots and TLS scan results and store them in a secure, immutable bucket for the audit window.

What logging and monitoring capabilities are required?

Collect all relevant logs (authentication, privileged actions, network traffic, configuration changes) in a centralized SIEM such as Splunk, Datadog, Elastic or AWS Security Hub. Ensure logs are timestamped, include the actor identifier, and retain them for at least 12 months. Set up alerts for anomalous activity (failed logins, privilege escalations) and document the response process for each alert.

How often should vulnerability scanning be performed?

Run external vulnerability scans weekly and internal scans monthly. Use an automated scanner (Qualys, Nessus, OpenVAS) that outputs a report with CVE identifiers, severity scores and remediation deadlines. Track each finding in a ticketing system and record the closure date to demonstrate remediation within the defined SLA.

What does a SOC 2 incident response plan need to contain?

The IRP must list response roles, an escalation matrix, containment steps, eradication procedures and a post - incident review process. Test the plan at least annually with a tabletop exercise and keep the test report, participant sign - offs and any corrective actions as evidence.

How do I handle vendor risk for SOC 2 compliance?

Maintain an inventory of all third - party providers. For each vendor, collect its latest SOC 2 report or a completed security questionnaire. Review the vendor’s controls annually and document any identified gaps and remediation actions. Store the vendor risk assessment documents alongside other audit evidence.

What evidence is required for a Type II SOC 2 audit?

Auditors expect continuous - monitoring evidence that covers the entire observation window (6 - 12 months). Evidence must be timestamped, attributed to a person or system, and be complete for the period. Typical artifacts include log exports, configuration snapshots, ticket histories, MFA enrollment logs, key - rotation records and IRP test reports.

How does SOC 2 security overlap with other frameworks?

Many SOC 2 controls map directly to ISO 27001, NIST 800 - 53 and CMMC Level 2. Controls such as MFA, encryption, vulnerability management and access reviews can be reused across frameworks, reducing duplicate effort.

Where can I find more detailed guidance?

For a deeper dive into each CC and practical implementation tips, see the Vanta SOC 2 compliance guide and the SOC 2 auditors’ insights pages linked in the source table.