TRANSITION / LOADING
Preparing the next reviewable route and its evidence boundary.
Public boundary. This transition does not request credentials, payment details, or private incident evidence.
DELIVERABLES / EVIDENCE SHAPES
These representative output shapes show how technical observations become usable decisions for executives, engineers, procurement, risk owners, and continuity teams.
Template boundary. These are illustrative structures, not client reports, independent assurance, certification evidence, government records, or proof of a particular engagement.
// REPRESENTATIVE OUTPUTS
The final deliverable depends on the agreed objective, authority, evidence, framework, and audience. The shapes below make the expected conversation visible before work begins.
Decision owner / board / procurement
Boundary: A decision aid, not a legal opinion, audit opinion, certification, or guarantee.
Security / engineering / operations
Boundary: A register reflects the agreed scope and evidence; it does not prove that an untested surface is safe.
Procurement / risk / third-party owner
Boundary: A questionnaire response is not independent assurance and a review is not a supplier verdict.
Assurance / compliance / control owners
Boundary: Readiness support does not create certification, accreditation, clearance, or regulatory approval.
Continuity / incident / service owner
Boundary: A plan or tabletop does not prove recovery until the relevant capability is exercised and evidenced.
Decision owner / remediation owner
Boundary: A retest is bounded evidence about the changed scope, not a permanent security guarantee.
// EVIDENCE REQUEST / ACCEPTANCE
This orientation map helps a buyer prepare a proportionate starting set for each service. It is not a universal client checklist, a classification policy, an authorization, a certification route, or a substitute for the applicable contract and owner decision.
| Engagement lane | Safe starting evidence | Review or verification method | Decision or acceptance condition |
|---|---|---|---|
| Authorized penetration testing | Written authority, in-scope assets, exclusions, rules of engagement, safety contact, and stop conditions. | Review authority and scope before any technical activity; confirm permitted methods, escalation, and evidence boundaries. | Named authority approves the scope, safety controls, permitted activity, and report audience. |
| Vulnerability assessment | Asset boundary, inventory or scanner context, source date, access permission, and the owner who can validate observations. | Reconcile the source and scope, verify material observations where permitted, and record severity, confidence, and limitations. | Security or engineering owner accepts the prioritized treatment path or records an authorized exception. |
| Cyber risk management | Mission or business objective, risk criteria, important services, existing controls, decision owner, and review date. | Map evidence to the risk question, control state, impact, likelihood, assumptions, and available treatment choices. | Risk or executive owner records treatment, transfer, avoidance, monitoring, or residual-risk acceptance. |
| Technical due diligence | The material decision, architecture boundary, delivery practices, critical dependencies, resilience evidence, and open questions. | Use bounded document, interview, and technical review methods; distinguish evidence, assumptions, gaps, and material unknowns. | Decision owner acknowledges the open questions, conditions, limitations, and decision implications. |
| Vendor due diligence | Supplier service and data flow, access model, subprocessors, continuity, incident evidence, contract context, and exit assumptions. | Check evidence provenance, coverage, recency, relationship fit, concentration, access, incident, and exit gaps. | Procurement or third-party risk owner records approval, conditions, mitigation, escalation, or decline. |
| Compliance readiness | Applicable requirement or contract, jurisdiction, control register, evidence owner, exception state, and target review date. | Confirm applicability and map evidence to the requirement; use sampling or specialist review without presenting the work as certification. | Control owner records the gap, exception, remediation route, or referral to the appropriate assessor or authority. |
| Disaster recovery and BCP | Critical service, business impact, dependencies, recovery assumptions, RTO/RPO discussion, runbooks, and exercise authority. | Review or exercise the agreed scenario, record decisions and observed results, and preserve unresolved dependency and recovery gaps. | Continuity or service owner accepts the exercise result, owned actions, residual risk, and next exercise or restore test. |
| Incident readiness | Roles, escalation contacts, scenario, communications path, evidence boundary, exercise authority, and participant list. | Run a bounded tabletop or exercise, record decisions and evidence handling, and separate exercise observations from a live incident. | Incident or executive owner approves the lessons-learned backlog, communications actions, and next readiness review. |
// PROCUREMENT / VENDOR RISK EVIDENCE PATH
This path helps a procurement or third-party-risk team turn a supplier conversation into a bounded, reviewable evidence record. It separates the service boundary, verification method, confidence, accountable owner, and next gate.
Use the first-brief template
Check framework fit
Review information handling
| Evidence lane | Safe starting evidence | Review or verification method | Record for the decision | No-fit condition |
|---|---|---|---|---|
| 01Boundary and data flow | Service purpose, users, geography, data categories, access paths, critical dependencies, subprocessors, and material fourth parties. | Confirm the boundary with the procurement, service, security, and supplier owners; reconcile the service description with the proposed relationship. | Scope state, accountable owner, source date, and review trigger. | A generic architecture diagram or supplier description is not a complete boundary. |
| 02Control and incident posture | Current control summary, independent reports where applicable, incident route, notification terms, logging context, and unresolved exceptions. | Check provenance, coverage period, applicability, exclusions, exceptions, and whether the evidence addresses the actual service rather than the supplier generally. | Evidence state, provenance, confidence, limitation, and owner question. | A questionnaire answer or marketing claim is not independent assurance. |
| 03Access and third parties | Privileged access model, identity controls, support access, subprocessor or fourth-party register, segregation, monitoring, and review cadence. | Map who can access what, why access is needed, how it is approved, and how the relationship changes when the contract or service changes. | Access/data map, open gap, accountable owner, and decision condition. | Do not request secrets, private keys, credentials, or unnecessary customer records. |
| 04Continuity and exit | Critical-service dependencies, recovery assumptions, RTO/RPO context, tested recovery, portability, exit assistance, concentration, and substitution assumptions. | Tie continuity claims to an exercise, restore, or other permitted evidence; inspect dependencies and contract conditions that could affect exit or recovery. | Observed result, unresolved dependency, treatment action, and next test or review date. | A documented plan without an observed test is not proof of recovery. |
| 05Findings and exceptions | Open findings, risk acceptances, compensating controls, remediation commitments, material incidents, and overdue actions relevant to the service. | Check scope, owner, date, severity, residual risk, evidence quality, and the trigger that would cause escalation or re-review. | Action record, confidence, acceptance authority, due date, and escalation path. | Absence of supplied evidence is not evidence of a clean result. |
| 06Acceptance gate | The conditions, limitations, decisions, and follow-up work required from procurement, security, legal, continuity, service, and risk owners. | Record what is accepted, conditioned, deferred, escalated, or declined; identify the owner and the date or event that reopens the question. | Decision, accountable owner, residual-risk treatment, and revisit date. | ZeroDev does not approve a supplier, provide legal advice, or accept residual risk for the customer. |
// SYNTHETIC REVIEW PREVIEW
A useful deliverable makes the decision, boundary, evidence state, owner, treatment, and closeout condition visible together. This example is intentionally synthetic and contains no client, provider, target, or production evidence.
| Brief field | Illustrative entry | Evidence state / boundary |
|---|---|---|
| Decision question | Can a critical public-facing service proceed to the next approved change window? | Synthetic question / not a client decision |
| Agreed boundary | Illustrative external application surface; no live target, customer record, credential, or production export is included. | Template scope / no live assessment |
| Evidence state | A reported access-control assumption is awaiting scope confirmation and permitted verification. | Observed / pending verification |
| Treatment path | Named service owner confirms the control, records the risk choice, and agrees a retest or review condition. | Recommended action / owner required |
| Closeout condition | Record what changed, what was rechecked, what remains open, and the next review trigger. | Rechecked / closure evidence required |
// EVIDENCE STATE
A credible review keeps the evidence state visible. A document can be received without being complete, authentic, current, applicable, or independently verified.
Requested — the evidence item and reason are defined.
Received — a source was supplied, without assuming it is accurate or complete.
Verified — the agreed verification method and limitations are recorded.
Interpreted — the evidence is connected to a control, risk, decision, or service.
Accepted or excepted — the responsible owner records treatment or residual risk.
Rechecked — a changed control, recovery capability, or open question is reviewed again.
// PROVENANCE / CONFIDENCE
A review becomes more defensible when a reader can see where the evidence came from, what it covers, how it was checked, what remains uncertain, and when the conclusion should be revisited.
Use the claims-to-proof matrix before turning evidence into a public claim
| Provenance field | Record | Confidence signal | Boundary |
|---|---|---|---|
| Source identity | Origin, owner, revision or observation date, and a stable reference. | A named source has a traceable revision, date, or explicit synthetic label. | An unattributed, stale, or untraceable source remains unverified. |
| Scope and applicability | System, service, contract, framework, jurisdiction, objective, exclusions, and intended audience. | The evidence matches the agreed question and the boundary being reviewed. | A relevant document outside the agreed scope does not prove the in-scope condition. |
| Method and confidence | Review, interview, sampling, test, exercise, or independent verification method and sample limits. | The method, sample, limitations, and confidence basis are visible to the decision-maker. | Confidence describes evidence quality; it is not a security guarantee or auditor opinion. |
| Interpretation and limitation | Observed, verified, assumed, disputed, missing, and unresolved elements. | Facts, analysis, assumptions, and open questions are kept distinct. | Interpretation does not create legal, procurement, regulatory, or certification authority. |
| Owner and decision | Accountable owner, decision owner, treatment, exception, and acceptance authority. | A named owner acknowledges the conclusion and the next action. | A report cannot accept residual risk on behalf of an organization. |
| Review trigger and disposition | Retest, exercise, contract change, threat update, requirement change, and retention or disposition date. | The record states when evidence expires, changes meaning, or needs rechecking. | A historical pass does not prove current security, resilience, or continuity. |
// REDACTION / HANDLING
Any public or early-stage review material should be sanitized. Do not place credentials, tokens, private keys, customer records, payment details, private incident evidence, unredacted inventories, live target details, exploit payloads, or confidential government or defense information into ordinary email or public pages.
Use synthetic, redacted, or abstracted examples for discovery. Establish the authorized handling path, minimum necessary evidence, retention boundary, and decision owner before sensitive material is exchanged.
// NEXT MOVE
Start with the decision, audience, scope, and authority. The deliverable shape can then be adapted to the engagement without inventing certainty.
Prepare the first brief
Review the methodology
Review the remediation lifecycle