Does SOC 2 require MFA, MDM, penetration testing, background checks or a SIEM?

Not as a fixed rule. CC6.1 names multifactor authentication as a point of focus, to be used where your risk assessment calls for it, and CC6.6 expects extra authentication for access from outside your systems. In practice it is the control auditors most expect: without MFA on email, the identity provider, cloud consoles and production, it is hard to show logical access is restricted.

Maps to: CC6.1 (logical access security; its points of focus name multifactor authentication) and CC6.6 (protecting against threats from outside the system boundary; additional authentication is required for access from outside).

What auditors usually accept: An export or screenshot from the identity provider showing MFA enforced for all users, the same for cloud consoles and code hosting, and a list of exceptions with reasons.

What a startup can do: Turn on MFA enforcement in your identity provider and in every admin console that does not sign in through it. This costs nothing and closes the most common finding.

No. No criterion names MDM. The auditor needs evidence that laptops and phones reaching customer data are encrypted, locked, patched and protected from malware.

Maps to: CC6.1 (its points of focus include encrypting data at rest where your risk assessment calls for it), CC6.7 (points of focus: protecting endpoint devices such as laptops and mobile devices, and encrypting removable media) and CC6.8 (preventing or detecting unauthorised or malicious software).

What auditors usually accept: A device inventory, the device policy, and per-device proof of disk encryption, screen lock, OS updates and anti-malware for a sample of devices, covering the whole period in a Type 2.

What a startup can do: Under about 25 people, a reporting agent or dated screenshots against a written device standard is usually enough. See Do I need MDM? for when full MDM pays off.

Not explicitly. SOC 2 requires you to evaluate whether controls work and to find vulnerabilities; a yearly penetration test is the most common way to do both, and many buyers ask for the report.

Maps to: CC4.1 (ongoing and separate evaluations of controls; the points of focus list penetration testing as one type) and CC7.1 (detection procedures for configuration changes and newly discovered vulnerabilities).

What auditors usually accept: A penetration test report from the period, with findings tracked to closure, and evidence of regular vulnerability scanning with remediation timelines.

What a startup can do: Run automated vulnerability scanning on your application and cloud from day one, with an SLA for fixing findings. Commission a third-party test before the first enterprise deal asks for one.

Not by name. The criteria require you to hire and keep competent, trustworthy people; background checks, where local law allows them, are the usual way to show it.

Maps to: CC1.1 (commitment to integrity and ethical values) and CC1.4 (attracting, developing and retaining competent individuals).

What auditors usually accept: A hiring policy that says which checks apply to which roles, and evidence for a sample of new hires: a completed check, or a reference check where background checks are restricted.

What a startup can do: Write the screening policy to match the law in each country you hire in, apply it to every hire in scope, and keep the record. Reference checks and signed codes of conduct are acceptable where checks are not.

No. SOC 2 requires you to monitor systems for anomalies and to evaluate security events. A SIEM is one way; cloud-native alerting with a defined review process is another.

Maps to: CC7.2 (monitoring system components for anomalies indicating malicious acts, natural disasters and errors) and CC7.3 (evaluating security events to decide whether they are incidents).

What auditors usually accept: Alert rules for the events that matter (failed and privileged logins, configuration changes, data exports), evidence alerts reach a person, and tickets showing alerts were triaged during the period.

What a startup can do: Use your cloud provider's native threat detection and audit logs, route alerts to a channel someone owns, and record triage. Buy a SIEM when log volume or customer contracts demand it.

Not by algorithm, but auditors expect encryption in transit and at rest for customer data, and on laptops that hold it.

Maps to: CC6.1 (encryption is a point of focus for protecting data) and CC6.7 (encryption or secure channels for data in transmission and movement).

What auditors usually accept: Configuration evidence that databases, storage and backups are encrypted at rest, TLS on every public endpoint, key management settings, and disk encryption on devices.

What a startup can do: Use your cloud provider's default encryption at rest and managed keys, enforce TLS, and turn on disk encryption on every laptop.

Yes in substance. You cannot meet the monitoring and incident criteria without logs of access and changes to systems in scope, kept long enough to investigate.

Maps to: CC7.2 and CC7.3 (monitoring and evaluating events), with CC8.1 (change management) relying on change records.

What auditors usually accept: Audit logging enabled for the identity provider, cloud accounts, databases and code hosting, a retention setting, and examples of logs used in an investigation or review.

What a startup can do: Turn on cloud audit logs and identity provider logs, centralise them in one place, and set retention to at least the audit period.

Yes in substance. You must assess and manage the risk from vendors that handle customer data or run part of your system.

Maps to: CC9.2 (assessing and managing risks associated with vendors and business partners).

What auditors usually accept: A vendor inventory with risk ratings, the vendors' SOC 2 reports or questionnaires reviewed at least yearly for critical vendors, and contracts with security terms.

What a startup can do: List every vendor that touches customer data, collect their SOC 2 or ISO 27001 reports once a year, and note what you checked. The complementary user entity controls in their reports are yours to meet.

Yes in substance. The criteria require control activities deployed through policies and procedures, communicated to staff.

Maps to: CC5.3 (control activities deployed through policies and procedures) and CC2.2 (internal communication of objectives and responsibilities).

What auditors usually accept: Approved policies with owners and review dates, evidence staff acknowledged them, and procedures that match what people actually do.

What a startup can do: Start with a short set: information security, acceptable use, access control, incident response, vendor management and change management. Short and followed beats long and ignored.

• AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
• AICPA: SOC 2, SOC for Service Organizations: Trust Services Criteria

Checked October 2026. For whether you need a report at all, use the Do I need SOC 2? checker; for the criteria and report types, the SOC 2 guide and Type 1 vs Type 2.