Do you need everything finished before starting?
No. Readiness work starts by understanding the requirements and the current state. You do need enough business context, access and team participation to define what will be reviewed and make decisions about gaps.
You can begin with incomplete controls or missing evidence. Identify those limits openly so the plan includes the work needed to address them.
Define the requirement and the boundary
Bring the actual customer request, contract requirement or target framework. “We need compliance” is too broad to scope. Clarify which service, business entity, systems and information are involved, who will review the outcome and what they expect.
For DoD contractors preparing for CMMC, bring the requested level and assessment path, identify where federal contract information (FCI) and controlled unclassified information (CUI) are handled, and review the proposed system boundary with your providers. A system security plan, where available, gives the discussion a useful starting point. Use the official DoD assessment and scoping guides alongside the actual contract requirements.
A customer questionnaire, SOC 2 examination and ISO 27001 certification involve different processes. Agree the target and engage the appropriate external assessor early when required. Readiness support does not issue an audit opinion or certification.
Collect a useful starting set
- People and systems: a current inventory, system owners, key vendors and information flows.
- Policies and responsibilities: approved documents, named owners and the process for updating them.
- Access: how people join, change roles and leave; how privileged access is approved and reviewed.
- Recovery and response: current plans, contact responsibilities and available exercise or recovery-test records.
- Operational records: change approvals, security training, vulnerability handling and other records relevant to the chosen requirements.
This is a discovery starting point, not a universal compliance checklist. The agreed requirements determine the control and evidence set.
Distinguish a control from its evidence
A written policy describes expectations. Evidence shows what happened, when it happened and who reviewed it. A useful record is linked to the relevant system, time period and requirement.
For example, an access-review policy is different from the actual review record: accounts checked, reviewer, exceptions and follow-up decisions. Buying a compliance tool does not by itself demonstrate that the process is operating.
The work continues after the initial review. Identify recurring activities, their owners and the records needed to show that they happened. Examples include access reviews, training, vulnerability follow-up and recovery exercises; the applicable requirements determine the actual activities and cadence.
Use the illustrative evidence index to organize records and expose missing owners or dates. Store sensitive evidence in an approved system; a public download is only a planning template.
Confirm who can do the work
Assign an executive sponsor and the control owners who can approve, implement and document changes. Agree what your IT team, MSP, HR, legal and other partners will contribute. Put availability and decision deadlines into the plan.
Readiness can stall even when the gap list is correct if nobody has authority or capacity to close it. Commitment means making decisions, assigning owners, providing staff time and funding the agreed changes. Your initial quote and schedule should account for those dependencies.
Scope readiness from your current state
Bring what exists today, including incomplete records. Explore compliance readiness support, the inputs behind a quote, and how scope and evidence affect timing.
