What auditors ask about SOC 2 policies

A SOC 2 examination starts with a document request list, and policies are the first section of it. After the documents arrive, the auditor walks through them with the person who owns security and asks questions to confirm that what is written is what happens. Below are the 25 questions that come up in almost every walkthrough, a plain answer for each, and the document you would point to.

How the policy review actually works

For a Type I examination, the auditor is assessing whether your controls are suitably designed as of a date. For policies that means three things: the policy exists and is approved, it describes a control that would meet the relevant criterion if operated, and the people responsible know about it. For a Type II they add a fourth: the procedures in the policy ran on the stated cadence during the observation period, and you can show samples. See Type I vs Type II for the differences.

The walkthrough is a conversation, typically 60 to 90 minutes with the Security Owner and the Engineering Lead, sometimes with an HR lead for the people-related questions. The auditor will have read the policies and will ask “show me” questions: show me the last access review, show me the ticket for a recent production change, show me a signed acknowledgment. The answers below tell you what to have open on screen.

The document references use the Policyseed policy IDs (P01 to P22). The four other documents (the TSC crosswalk, evidence checklist, acknowledgment forms and review calendar) are part of the Audit Kit; the free generator produces the 22 policies only.

The questions

1. Do you have a formally approved information security policy, and who approved it?

Yes. The Information Security Policy (P01) is the top-level document. Its Revision History table records version 1.0, the effective date, and the name and title of the approver you entered at intake. Every other policy in the kit uses the same approver and effective date, so the auditor sees one consistent approval record across all 22 documents.

Supporting documents: P01 Information Security Policy, Policy review calendar (Audit Kit)

2. Who is responsible for security at the company, and is that written down?

Section 3 (Roles and Responsibilities) of the Information Security Policy names the Security Owner, the approver, the Engineering Lead and the other owner roles, and each policy carries a named owner role in its front matter. The Policy Review Calendar names the owner role of every policy in its review sessions, so accountability is visible at a glance.

Supporting documents: P01 Information Security Policy, P17 Risk Assessment and Management Policy, Policy review calendar (Audit Kit)

3. How do you make sure employees have read and agreed to the policies?

The kit includes a policy acknowledgment form for each employee that lists all 22 policies with a signature line and date. The Human Resources Security Policy (P18) requires acknowledgment at onboarding and after every annual review, and the Acceptable Use Policy (P02) requires a separate signed acknowledgment. Keep the signed forms; they are evidence for CC1.1, CC1.5, CC2.2 and CC5.3.

Supporting documents: P02 Acceptable Use Policy, P18 Human Resources Security Policy, Acknowledgment forms (Audit Kit)

4. How often are policies reviewed, and can you show the last review?

Section 8 (Review Cadence) of every policy states the cadence you chose at intake (annual, semi-annual or quarterly). The Policy Review Calendar (.ics) schedules eleven monthly review sessions that cover every policy, followed by an annual attestation of the whole set. After the first review, add a row to the Revision History table of each policy; that row is the evidence for CC5.3.

Supporting documents: P01 Information Security Policy, Policy review calendar (Audit Kit)

5. Which Trust Services Criteria do these policies cover, and how do I know which policy addresses which criterion?

The TSC Crosswalk maps every criterion in your selected scope (the 33 common criteria, plus Availability and Confidentiality when selected, up to 38 in the 2017 TSC) to the specific policy and section that addresses each one. Each Word document also lists its criteria in the document control table. The crosswalk is included as a spreadsheet so the auditor can filter by criterion or by policy.

Supporting documents: TSC crosswalk (Audit Kit)

6. Have you performed a risk assessment, and how is it documented?

The Risk Assessment and Management Policy (P17) defines the annual risk assessment, the scoring scale and the risk register format in Sections 4 and 5. The policy itself is the process document; the completed risk register is an artifact you produce by following Section 5. The Evidence Checklist lists the risk register as required evidence for CC3.1 through CC3.4 and CC5.1.

Supporting documents: P17 Risk Assessment and Management Policy, Evidence checklist (Audit Kit)

7. How is access to production systems granted, and who approves it?

The Access Control Policy (P03) Section 4 sets role-based access and least privilege, and Section 5 describes the request and approval workflow. With the Audit Kit, Section 4 and 5 are tailored to your identity provider, cloud and source control platform, so the procedures reference the actual groups and roles you use. The Evidence Checklist lists the access request tickets and role matrix as evidence for CC6.1 through CC6.3.

Supporting documents: P03 Access Control Policy, Evidence checklist (Audit Kit)

8. Do you perform periodic access reviews?

Yes. The Access Control Policy (P03) Section 5 requires a quarterly review of user and privileged access, signed by the Security Owner. The Evidence Checklist names the quarterly access review spreadsheet as evidence for CC4.1, CC6.2 and CC6.3; add a quarterly reminder to your own calendar, since the Policy Review Calendar covers policy reviews rather than access reviews.

Supporting documents: P03 Access Control Policy, Evidence checklist (Audit Kit)

9. Is multi-factor authentication enforced, and where?

The Authentication and Password Policy (P04) Section 4 requires MFA for the identity provider, source control, cloud consoles and any system holding customer data, based on the MFA answer you gave at intake. The Evidence Checklist lists the identity provider MFA enforcement screenshot as evidence for CC6.1 and CC6.6.

Supporting documents: P04 Authentication and Password Policy, Evidence checklist (Audit Kit)

10. What happens when an employee or contractor leaves?

The Human Resources Security Policy (P18) Section 5 defines the offboarding procedure, and the Access Control Policy (P03) Section 5 sets the deadline for removing access. The Asset Management Policy (P05) covers device return and wipe. The Evidence Checklist lists the offboarding checklist and identity provider deactivation timestamp as evidence for CC6.2 and CC6.5.

Supporting documents: P03 Access Control Policy, P05 Asset Management Policy, P18 Human Resources Security Policy, Evidence checklist (Audit Kit)

11. Do you conduct background checks and security training?

The Human Resources Security Policy (P18) Section 4 requires background checks where legally permitted and security awareness training within 30 days of hire and annually. The training completion report and background check confirmations are listed in the Evidence Checklist under CC1.4.

Supporting documents: P18 Human Resources Security Policy, Evidence checklist (Audit Kit)

12. How do you classify data, and how is customer data handled?

The Data Classification and Handling Policy (P06) defines the classification levels and the handling rules for each in Section 4, including the data types you selected at intake (PII, PHI, payment data). The Privacy and Data Protection Policy (P22) covers personal data specifically. Both are mapped to C1.1 and CC6.7 in the crosswalk.

Supporting documents: P06 Data Classification and Handling Policy, P22 Privacy and Data Protection Policy, TSC crosswalk (Audit Kit)

13. How long do you retain data, and how do you dispose of it?

The Data Retention and Disposal Policy (P07) Section 4 sets retention periods by data category and Section 5 defines secure deletion, including removal from backups. The Asset Management Policy (P05) covers physical media. The Evidence Checklist lists lifecycle policy screenshots and deletion request records for C1.2 and CC6.5.

Supporting documents: P05 Asset Management Policy, P07 Data Retention and Disposal Policy, Evidence checklist (Audit Kit)

14. Is data encrypted at rest and in transit, and how are keys managed?

The Encryption and Key Management Policy (P08) Section 4 requires TLS 1.2 or higher in transit and provider-managed encryption at rest for databases, object storage and backups, and describes key rotation and access. The Evidence Checklist lists the encryption-at-rest settings screenshot and a TLS scan result for CC6.1 and CC6.7.

Supporting documents: P08 Encryption and Key Management Policy, Evidence checklist (Audit Kit)

15. How are changes to production reviewed, tested and approved?

The Change Management Policy (P09) Sections 4 and 5 require peer review, automated tests and approval before merge, with emergency change handling. The Secure Software Development Policy (P10) covers the development practices. With the Audit Kit these sections reference your source control platform and CI/CD tool by name. Branch protection export and sample pull requests are listed as evidence for CC8.1.

Supporting documents: P09 Change Management Policy, P10 Secure Software Development Policy, Evidence checklist (Audit Kit)

16. How do you find and fix vulnerabilities, and what are your remediation timelines?

The Vulnerability and Patch Management Policy (P11) Section 4 sets severity-based remediation timelines and Section 5 describes scanning, dependency monitoring and patching. The Evidence Checklist lists scan reports and the remediation tracker for CC7.1 and CC6.8.

Supporting documents: P11 Vulnerability and Patch Management Policy, Evidence checklist (Audit Kit)

17. What logging and monitoring is in place, and who responds to alerts?

The Logging and Monitoring Policy (P12) Section 4 defines which events are logged, how long logs are kept and what is alerted on; Section 5 covers alert triage. With the Audit Kit it references your logging tool by name. The alert rules export and a sample alert with its response are listed as evidence for CC7.2.

Supporting documents: P12 Logging and Monitoring Policy, Evidence checklist (Audit Kit)

18. Do you have an incident response plan, and has it been tested?

The Incident Response Policy (P13) defines severity levels, roles, the incident contact you provided at intake, containment steps, customer notification and post-mortems. Section 5 requires an annual tabletop exercise. The tabletop notes and any incident records are listed in the Evidence Checklist for CC7.3 through CC7.5.

Supporting documents: P13 Incident Response Policy, Evidence checklist (Audit Kit)

19. How would customers be notified of a security incident affecting their data?

The Incident Response Policy (P13) Section 5 includes the customer notification step and timeline, and the Privacy and Data Protection Policy (P22) covers regulatory notification for personal data. The Vendor and Third-Party Risk Policy (P16) requires vendors to notify you so you can meet those commitments. The crosswalk maps this to CC2.3 and CC7.4.

Supporting documents: P13 Incident Response Policy, P22 Privacy and Data Protection Policy, P16 Vendor and Third-Party Risk Management Policy, TSC crosswalk (Audit Kit)

20. What are your backup and disaster recovery arrangements, and do you test them?

The Backup and Recovery Policy (P15) sets the backup schedule (from your intake answer), retention and encryption, and requires restore testing. The Business Continuity and Disaster Recovery Policy (P14) sets recovery objectives and requires an annual recovery exercise. These are mapped to A1.2, A1.3, CC7.5 and CC9.1; the restore test record is the key evidence artifact.

Supporting documents: P14 Business Continuity and Disaster Recovery Policy, P15 Backup and Recovery Policy, Evidence checklist (Audit Kit)

21. How do you manage vendor and third-party risk?

The Vendor and Third-Party Risk Management Policy (P16) Section 4 requires a vendor inventory with criticality tiers, security review before onboarding, contractual security terms and annual review; Section 5 describes the review procedure. The vendors you listed at intake appear in the policy. The signed DPA and SOC 2 review notes are listed as evidence for CC9.2.

Supporting documents: P16 Vendor and Third-Party Risk Management Policy, Evidence checklist (Audit Kit)

22. How are laptops and other endpoints secured?

The Endpoint and Workstation Security Policy (P19) Section 4 requires disk encryption, screen lock, endpoint protection, automatic updates and device management (referencing your MDM if you have one). The Asset Management Policy (P05) keeps the device inventory. The MDM compliance report is the primary evidence for CC6.6, CC6.7 and CC6.8.

Supporting documents: P05 Asset Management Policy, P19 Endpoint and Workstation Security Policy, Evidence checklist (Audit Kit)

23. How do you address physical security, for offices and for remote staff?

The Physical and Remote Work Security Policy (P21) Section 4 covers home office requirements, public network use, screen privacy and any office access, and relies on the cloud provider's SOC 2 report for data center controls. The crosswalk maps it to CC6.4, CC6.5 and A1.2.

Supporting documents: P21 Physical and Remote Work Security Policy, TSC crosswalk (Audit Kit)

24. How is your network and cloud infrastructure secured?

The Network and Infrastructure Security Policy (P20) Section 4 requires network segmentation, restricted inbound access, secure administrative access and infrastructure as code with configuration monitoring, tailored to the cloud providers you selected. Firewall rule exports and configuration monitoring alerts are listed as evidence for CC6.1, CC6.6 and CC7.1.

Supporting documents: P20 Network and Infrastructure Security Policy, Evidence checklist (Audit Kit)

25. What evidence should we expect you to have ready for the Type I examination?

The Evidence Checklist spreadsheet lists, for every criterion in your selected scope, the policy section that addresses it, two to four concrete artifacts to collect, and the owner role responsible. Work through it before the examination date and attach or link each artifact. The checklist does not replace the CPA firm's own request list, but it covers the artifacts a small SaaS company is typically asked for.

Supporting documents: Evidence checklist (Audit Kit), TSC crosswalk (Audit Kit), Acknowledgment forms (Audit Kit), Policy review calendar (Audit Kit)

How to prepare in one afternoon

  1. Open each policy and check the three fields the auditor checks first: owner role in the front matter, the revision history row (version, effective date, approver), and the review cadence in section 8. Inconsistencies between policies are the most common early finding.
  2. For each question above, find the artifact. A screenshot with a visible date, a ticket, a signed form, a calendar entry, an export from the identity provider. Put them in one folder named by policy ID. The evidence checklist in the Audit Kit lists what to collect for each criterion.
  3. Fix the policy or fix the control, never the evidence. If a procedure has not run, either run it now (a restore test takes an hour) or change the policy to state when it will first run.
  4. Rehearse the four hard ones: access (7, 8, 10), change management (15), incident response (18, 19) and vendors (21). These get the most follow-up questions because they map to the most criteria.
  5. Collect acknowledgments before fieldwork. Question 3 is asked in every examination and the evidence takes a week to gather if you have contractors. See the acknowledgment guide.

For the full set of policies and who should own each, see SOC 2 policies for startups. Templates are at the template index; the Audit Kit and Agency licence are on the pricing page.

Frequently asked questions

Will the auditor read every policy word for word?
Usually not in the walkthrough, but the request list asks for all of them and a reviewer will read them before fieldwork. Expect detailed questions on Access Control, Change Management, Incident Response and Vendor Management, and spot checks on the rest for owners, dates and consistency.
What if my honest answer to one of these questions is “we do not do that yet”?
Say so, and fix the policy so it does not claim otherwise. A policy that says access reviews are quarterly when none has happened is a finding. A policy that says the first review is scheduled for a named month, with the calendar entry to prove it, is a plan the auditor can assess.
Do I need to prepare written answers?
Not formally, but the person answering should know which document and which section supports each answer. The Audit Kit includes this question bank with the supporting document for each answer so the Security Owner can rehearse.
Are these the actual questions my auditor will use?
Every CPA firm has its own request list and walkthrough script. These 25 questions are the ones that appear, in some form, in almost all of them. They are written in our own words and are not taken from any firm’s materials or from the AICPA’s criteria text.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.