What the conversation should produce.
- A reconciled scope list with each asset marked as confirmed, suspected or unknown
- A logging status table documenting which systems record events and where gaps exist
- A readiness review decision record stating whether the team proceeds, reduces scope or postpones
Confirm the business owner, technical owner and decision to support
Identify the business and technical responsibilities relevant to the engagement. One person may hold more than one role, but the responsibilities should still be clear: who defines the decision, who understands the environment, who can authorise the work and who can pause it. Record how those roles coordinate, including cover when a contact is unavailable. The purpose is a workable decision structure, not an assumed requirement for a particular number of people or signatures in every organisation.
The decision to support must be explicit, not assumed. Silence from a department often means caution, not consent. A readiness checklist should record each owner's name, role, contact and the date they confirmed participation. If a department cannot confirm, the assessment must either delay that area or reduce its scope. Ambiguous ownership can delay decisions and leave important constraints unresolved. Clear ownership also determines who receives findings, who approves remediation and who bears the cost of any disruption. Record these choices before any technical work begins.
Reconcile the asset list and distinguish known from uncertain scope
An asset list is a hypothesis until verified. Many organisations maintain spreadsheets that are outdated or incomplete. The first practical step is to reconcile the list against live systems, network diagrams and cloud consoles. Mark each item as confirmed, suspected or unknown. Confirmed assets can be included in scope. Suspected assets require further investigation before testing. Unknown assets must be excluded until the owner can verify them. This distinction protects the assessment from false conclusions and prevents accidental testing of systems that were never intended to be included.
Scope reconciliation is an ongoing activity, not a one-time task. New systems appear, old ones are retired and cloud resources are spun up without central record-keeping. The assessment team should maintain a running log of scope changes, with dates and the person who authorised each change. When scope is uncertain, the safer choice is to exclude the item and document the exclusion. Testing an unverified system risks disruption and produces findings that cannot be trusted. A reconciled scope list is more valuable than a larger but unreliable one.
Prepare representative accounts, data and operational contacts
Prepare approved test accounts that represent the roles and relationships relevant to the question. Dedicated assessment accounts can be appropriate when their configuration reflects the intended conditions and their lifecycle is controlled. A single privileged account may answer some questions but leave other role boundaries unexamined. Record permissions, limitations and any differences from normal use. The aim is not to use live identities unnecessarily; it is to make the starting conditions understandable and the resulting observations interpretable.
Data preparation is equally important. Use data that represents relevant production structure and workflows without unnecessary sensitive content. Synthetic or appropriately prepared test records are a useful starting point. Synthetic data that matches the schema and volume of real data allows meaningful testing of access controls, search functions and data flows. Operational contacts must be identified for each system: the person who can confirm availability, the person who can restore a service and the person who can escalate a disruption. Record these contacts in a single reference document so the assessment team never has to search for them during an incident.
Check logging, recovery dependencies and pause communications
Identify the logging and observation needed for the selected question. A detection exercise may depend on specific event sources and access for the participating analysts; a different technical review may use configuration evidence or direct observations. Missing logs limit particular conclusions but do not automatically invalidate every kind of assessment. Record availability, relevant fields, access and retention with the owners. If a required source is absent, decide whether the objective should change or the prerequisite should be addressed before the affected activity begins.
Discuss operational dependencies and recovery arrangements with the teams responsible for them. The depth of preparation should reflect the agreed activity and potential effects, rather than a universal requirement to run a restoration test before every assessment. Confirm the relevant operating constraints, pause contacts and process for handling an unexpected impact. Where a recovery assumption is important but unverified, keep it visible in the readiness decision. Preparation reduces avoidable uncertainty; it does not guarantee that an exercise can have no operational effect.
Decide what to do when prerequisites are not ready
Prerequisites are rarely all satisfied on the first attempt. The assessment team must decide in advance how to respond when logging is incomplete, accounts are missing or scope is uncertain. The default response is to pause the affected area and document the gap. Pausing is not failure; it is discipline. Continuing without prerequisites produces unreliable findings and risks disruption. A decision matrix should specify which gaps are acceptable for a limited exercise and which gaps require a full pause. This matrix prevents ad-hoc decisions made under pressure.
Some gaps can be mitigated rather than resolved. Missing accounts can be replaced with a reduced set, with the limitation recorded. Incomplete logging can be accepted if the assessment focuses on areas where logging is confirmed. The key is to make the trade-off explicit and recorded. Do not proceed silently with reduced conditions, because the report will misrepresent the exercise. A transparent record of what was not ready and how the team responded is itself a valuable output, demonstrating intellectual honesty and operational maturity.
Use a readiness review to choose a suitable first engagement
A readiness review is a structured meeting that compares prerequisites against the proposed scope. The business owner, technical owner and assessment lead attend, review the reconciled asset list, confirm logging status and agree on which areas are ready. The output is a decision: proceed with the full scope, proceed with a reduced scope, or postpone. This decision is based on evidence, not optimism. The review should also identify which prerequisites are missing and who is responsible for resolving them. A readiness review converts uncertainty into a documented plan.
The first engagement should be the simplest one that still delivers value. A narrow scope with full readiness is more useful than a broad scope with unresolved gaps. Choose a system where logging is confirmed, accounts are prepared and the owner is engaged. Use the first engagement to validate the process, not to prove the assessment's capability. Subsequent engagements can expand scope as readiness improves. This approach builds trust gradually and produces findings that are credible, actionable and aligned with the organisation's actual capacity to respond.
Illustrative scenario: preparing a payroll system assessment
A mid-sized organisation plans to assess its payroll system. The business owner is the finance director, the technical owner is the HR systems manager. The asset list includes the payroll application, the database and two integration endpoints. The team reconciles the list and finds one integration endpoint is not in the network diagram. Logging is confirmed for the application but not for the database. The team prepares three representative accounts: a payroll clerk, an HR administrator and a service account for the integration. They identify the DBA as the operational contact for the database and confirm the backup restoration process works for the application. This scenario is illustrative and describes an illustrative situation.
- Exclude the unverified integration endpoint from scope and record the exclusion, because testing it would produce unreliable findings and risk disruption to an unknown system.
- Accept the database logging gap for the first engagement and focus on the application, documenting the limitation so the report accurately reflects what was verified.
- Proceed with the reduced scope as the first engagement, because it has confirmed logging, prepared accounts and an engaged owner, making it the simplest valuable option.
This scenario establishes that readiness decisions are evidence-based, not optimistic. It shows how to exclude uncertain items, accept documented limitations and choose a first engagement that matches actual preparedness. It does not prove the payroll system is secure or that the assessment will find specific issues.
Useful decision table for readiness choices
| Question | What to establish | Useful output |
|---|---|---|
| Is the asset list complete? | Reconcile against live systems and mark each item as confirmed, suspected or unknown | A reconciled scope list with documented exclusions |
| Are accounts representative? | Verify that prepared accounts mirror real role permissions and usage patterns | An account preparation log with limitations noted |
| Is logging sufficient? | Confirm which systems log events, where logs are stored and who can access them | A logging status table with gaps recorded |
| Can systems be restored? | Test backup restoration for at least one critical system and identify the responsible person | A recovery dependency record with restoration test results |
| Who decides when to pause? | Define the escalation path, notification channel and timeframe for operational contacts | A written escalation procedure signed by both owners |
Scroll the table horizontally on smaller screens.
Useful questions.
Can we skip the readiness review if the scope is small?
Scale the readiness check to the question and potential effects. A small engagement may need a brief, focused confirmation rather than a large workshop, but ownership, authority, boundaries and relevant prerequisites still need to be clear. Record the decision and unresolved items so the team understands what can proceed and under which conditions.
What if the technical owner refuses to prepare accounts?
Clarify why the accounts are unavailable and whether they are actually required for the selected question. An unauthenticated assessment may not need them, while a role-boundary review usually will. Agree a revised scope, resolve the prerequisite or postpone the affected activity. Do not create or obtain access outside the agreed authority, and record how the limitation affects the eventual conclusions.
Further reading: NIST SP 800-115: testing and assessment guidance. This independent resource provides background; no affiliation, certification or endorsement is implied.