The first reaction to a readiness checklist is that it is paperwork, and a surprising amount of it is. The part that is not paperwork is the part that matters to an engineering team, and it is worth separating them early so the work lands on the right people.
The distinction is simple. A policy is a document saying what you do. A control is the thing that makes it true. An auditor tests the second by asking for evidence, and evidence means a record produced automatically by a system rather than a screenshot somebody took last Thursday.
Evidence has to be a by-product
Any control whose evidence is collected by a person on a deadline will fail eventually, because the person will be on leave, or busy, or will collect it for the wrong week. The controls that hold up are the ones where the evidence is a natural artefact of the process: a merge that cannot happen without an approval, a deploy that records who triggered it, an access grant that writes an audit event whether or not anybody is watching.
So the readiness work is largely about moving processes into systems that keep records. Not because the auditor prefers it, but because a process without a record is indistinguishable from a process that did not happen.
- Change management: approval enforced by the tool, not by convention
- Access: grants and revocations as audit events with actor and timestamp
- Offboarding: a checklist that a system runs, not one a person remembers
- Monitoring: alerts that fire, are acknowledged, and leave a trail of both
A process without a record is indistinguishable, to anyone outside your team, from a process that did not happen.
Access review is where the time goes
Periodic access review sounds trivial and is not, because it requires answering who has access to what across every system you use, in a form somebody can approve. Most teams discover at this point that the answer lives in a dozen places, several of which only one person can log into.
Routing internal access through single sign-on collapses most of that into one list, which is the same argument you make to your own enterprise customers. It also makes revocation one action, which is the other half of the control — a review that identifies inappropriate access and takes three days to remove it is not much of a control.
Scope down, and say what is true
Scope is a decision you make and it is the biggest lever on effort. A report covering the production system that handles customer data is meaningful and achievable; one covering every internal tool your company has ever adopted is neither. Draw the boundary deliberately, document it, and keep it defensible.
Until a report exists, describe the position accurately: controls implemented, an audit planned, and a date. Marking a certification as planned is a normal answer that experienced reviewers accept. Implying one you do not hold is the single fastest way to lose a deal that was otherwise going to close.
- Define the system boundary before the work starts; scope creep is the main cost
- Prefer automated evidence over collected evidence in every case
- Do not claim a certification you do not hold — say implemented, planned, and when
- Ask which report your customer actually needs; the answer is often narrower than assumed
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.