Most readiness checklists are lists of controls. That is the wrong unit. An auditor does not ask whether you have a control; they ask for the record that proves it operated. A useful checklist is a list of things you must be able to hand over, and the condition each one must be in.
This one is organized the way the work arrives: agreeing scope, then the documents, then the controls and their owners, then evidence, people, vendors, and finally the logistics of fieldwork. Each item says what "ready" means. Where an item deserves a full treatment, it links to one.
It applies to SOC 2 and ISO 27001 in the main, with the differences noted. If you are auditing against something else, the shape holds, but confirm the specifics with your auditor or certification body.
When to work through it
Run the checklist twice. The first pass is before the period that will be tested begins: for a SOC 2 Type II, that is the start of the observation period; for a Type I or an ISO 27001 stage 2 audit, it is several weeks before the audit date. Anything found then can still be fixed without becoming a finding, which is the subject of fixing gaps before the observation period starts.
The second pass is a few weeks before fieldwork. By then the question changes from "does this exist?" to "can I produce it within an hour of being asked?"
Scope and engagement
Scope in writing. The systems, locations, teams, and services in scope, agreed with the auditor. For SOC 2, the trust services categories included. For ISO 27001, the scope statement that will appear on the certificate.
Exclusions with reasons. Every excluded system or team has a stated reason you would be comfortable defending.
Engagement letter signed. Dates, the period or audit window, and deliverables agreed.
The auditor's request list in hand. Most firms share a standard list on request. Map each item to an owner now, using the approach in the PBC list: handling auditor requests.
Subservice organizations identified. The providers you rely on, whether they will be carved out or included, and their own reports obtained.
Documents
Policies approved within the last year, by someone with the authority to approve them, with the approval dated.
Policies acknowledged by staff, with a record per person, including people who joined during the period.
Procedures that match practice. Read each one against how the work is really done. A procedure describing a step nobody performs is a finding waiting to be sampled.
SOC 2: the system description drafted. It is management's document and it is covered by the auditor's opinion, so every claim in it is testable.
ISO 27001: the core documented information. Scope, information security policy, risk assessment and risk treatment methodology, risk assessment results, risk treatment plan, and Statement of Applicability. The ISO 27001 framework page covers how these fit together.
ISO 27001: internal audit and management review complete. Certification bodies generally expect at least one cycle of each before stage 2, with records, and with any nonconformities the internal audit raised already being addressed.
Controls and owners
Every control has a named owner who has agreed to it. Not a name typed into a matrix. The difference is covered in assigning control owners who stay engaged.
Every control has a stated frequency, and the frequency in the description matches the frequency in practice.
No control is performed and reviewed by the same person on the same occurrence.
Control descriptions read as current. Systems that were replaced during the period are reflected, with the date of the change.
Automated controls have two records: the configuration that enforces them, and the change history showing who could alter that configuration and when it last changed. Auditors often rely on change management to trust an automated setting across the whole period.
Known failures are documented. Any missed occurrence has a written account: what happened, when it was found, and what was done.
Evidence and populations
Every sampled control has a population, pulled from the system of record, with the query or report saved. How to prove that list is complete is the subject of proving population completeness to an auditor.
Raw exports kept untouched, with when each was run and by whom.
Point-in-time evidence captured at the time. Access review inputs, user lists, and configuration exports from the dates they apply to, not regenerated later.
Evidence for every occurrence, not a representative one. If the auditor can pick any quarter's review, all four need to exist.
Configuration evidence dated and attributable. Exports or screenshots that show the system, the setting, and the date.
A test pull for the riskiest controls. Pick one occurrence of each of your hardest controls and assemble the full evidence set, as if it had been sampled. Anything that takes more than an hour goes on the work list.
People
A complete list of personnel for the period, including contractors and leavers, reconciled between HR and the identity provider.
Onboarding records for joiners: background checks where your policy requires them, policy acknowledgment, and security training, each dated within the window your policy states.
Offboarding records for leavers: termination date from HR and access removal from each in-scope system, with timestamps you can compare.
Security awareness training completion for everyone in scope, for the period, with the content version.
Vendors
An inventory of vendors in scope, with a risk tier for each.
A review record for each vendor due in the period, including the ones you decided were low risk. The tiering decision is the evidence for those.
Current assurance reports for your critical vendors, with a note of the review and any complementary user entity controls you are responsible for.
Contracts or data processing agreements for vendors that handle customer data, where your commitments require them.
Logistics for fieldwork
One coordinator owns the request tracker and every outgoing response.
A secure place to share evidence that both sides agree on, with access limited to the audit team.
Walkthrough slots booked with each control owner, in blocks rather than scattered across weeks.
Read-only access decided in advance. If the auditor will look at systems directly, the accounts, scope, and expiry are agreed before day one.
SOC 2: a representation letter expected. The attestation standards require the auditor to request written representations from management, usually as a letter signed near the end of fieldwork. Know who will sign it.
A rule for gaps. If something does not exist, the coordinator tells the auditor early, rather than letting the request sit.
Reading the result
You will not finish this list with every item complete. That is normal. Sort what is missing into three groups: items you can fix before the period or fieldwork starts, items that will be exceptions and need a written account, and items that are out of scope once you look closely. Take the second group to your auditor first. A disclosed gap is a conversation. A discovered one is a finding.
How TrustLynce helps
TrustLynce's readiness dashboard shows readiness per framework, with a gap analysis that maps each missing item to the control it affects. Requests, evidence, and findings then move through the auditor portal in one place.