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.
ENGAGE / SAFE FIRST BRIEF
Bring the question, the decision owner, and the outcome you need to make clearer. A high-level brief is enough to begin a useful conversation.
Do not send secrets. Keep credentials, tokens, customer records, private incident evidence, and live target details out of ordinary email. We can establish a safer exchange path after scope and authority are understood.
// PREPARE BY RESPONSIBILITY
The first brief becomes more useful when it names who owns the question, what decision is due, and what evidence can safely support it. Choose the closest responsibility; the service lane can remain undecided.
01 / Public-sector / government owner
Bring the program or procurement decision, accountable owner, public requirement or contract context, evidence-handling boundary, and what must be defensible. Keep controlled or restricted material out of ordinary email.
Safe first step: Keep the description high-level; do not attach credentials, customer records, private incident evidence, or live target details.
02 / Defense supplier / technology provider
Bring the prime, subcontract, or technology-provider context; system or service boundary; contract or requirement question; authorization owner; and supply-chain, continuity, or testing concern. Keep export-controlled, classified, and contract-restricted material out of ordinary email.
Safe first step: Keep the description high-level; do not attach credentials, customer records, private incident evidence, or live target details.
03 / Buyer / third-party-risk owner
Bring the relationship, service and data boundary, review purpose, evidence contact, contract or exit question, and the owner of the commercial or risk decision.
Safe first step: Keep the description high-level; do not attach credentials, customer records, private incident evidence, or live target details.
04 / Security / engineering / technical owner
Bring the named asset, service, or architecture boundary; the authorization owner; the safety contact; and the evidence or output the technical team needs to act on.
Safe first step: Keep the description high-level; do not attach credentials, customer records, private incident evidence, or live target details.
05 / Continuity / service / incident owner
Bring the critical service, impact priority, dependencies, recovery assumptions, decision date, and the authority to run a restore test, tabletop, or exercise.
Safe first step: Keep the description high-level; do not attach credentials, customer records, private incident evidence, or live target details.
// FIRST CONTACT
The first message is not a penetration-test authorization, incident submission, or evidence transfer. It is a way to decide whether a properly scoped engagement is appropriate.
The decision you need to make or the outcome you need to prove
Your sector, role, and high-level operating context
The engagement lane that seems closest, or the question that is still unclear
A high-level description of the system, supplier, service, or recovery concern
The intended audience for the output: technical, executive, procurement, legal, or risk
The target timeframe, decision date, and any known constraints
The named owner who can confirm authority, scope, and evidence handling
Any applicable contract, framework, data, or jurisdiction questions
// SAFE BRIEF TEMPLATE
Use these headings for an initial note. Leave unknown fields blank and keep sensitive evidence out until the recipient, purpose, and handling path are agreed.
Objective: What decision or outcome needs to become clearer?
Context: Sector, role, and high-level system, supplier, service, or recovery concern.
Service question: Assess, assure, recover, or not yet clear.
Audience and timing: Who needs the output, and when is the decision due?
Authority owner: Who can confirm ownership, scope, and permission to proceed?
Applicability and boundary: Any contract, framework, jurisdiction, exclusion, or safety constraint to consider.
Safe boundary: Do not add credentials, secrets, customer records, private incident evidence, or live target details to the template.
Context included: The email and copy actions include incident readiness as planning context only.
// ENGAGEMENT READINESS / SOW STARTER
This synthetic outline helps a public-sector, defense-supplier, procurement, security, continuity, or risk owner prepare a proportionate engagement record before a proposal or controlled exchange.
Owner gate. This is a readiness outline, not a proposal, statement of work, contract, authorization, classification policy, or certification evidence. The applicable contract, authority, handling process, and owner decisions control the real engagement.
Review the rules-of-engagement starter
Review deliverable acceptance shapes
Review claims and proof gates
| Readiness stage | Draft record | Owner acceptance or stop condition |
|---|---|---|
| 01Decision and outcome | Mission or service question, decision date, intended audience, and the outcome the work must make clearer or safer. | The decision owner confirms the objective; no technical activity is implied by a high-level brief. |
| 02Authority and scope | Named authority owner, written permission route, assets or services, inclusions, exclusions, timing, safety contact, and stop conditions. | The authority owner confirms the boundary and any changes; missing or mismatched authority pauses the work. |
| 03Rules and methods | Permitted review or test methods, prohibited actions, rate or availability limits, access assumptions, and escalation route. | The security or service owner confirms the method is proportionate; unapproved or unsafe activity is excluded. |
| 04Evidence and handling | Evidence sources, recency, confidence, minimum necessary data, redaction, transfer channel, retention, and restricted-information boundary. | The handling owner confirms the approved path; public pages and ordinary email remain high-level. |
| 05Deliverables and acceptance | Technical, executive, assurance, or resilience output; evidence states; limitations; audience; acceptance criteria; and named reviewer. | The responsible owner accepts a bounded record only; it is not certification, independent assurance, or a security guarantee. |
| 06Treatment and retest | Owners, priorities, treatment choice, residual-risk decision, retest or exercise condition, and review trigger. | The owner records remediation, exception, acceptance, retest, exercise, or escalation; ZeroDev does not accept risk for the client. |
| 07Closeout and change control | Access removal, temporary-change cleanup, unresolved questions, source or revision record, disposition, next review date, and approved change path. | The authority or service owner confirms closeout; unresolved or changed scope stays open or is re-authorized. |
// PRINT / INTERNAL REVIEW COPY
Use this static sheet for an internal review or to prepare a high-level message in an approved channel. It is not a submission form, authorization, proposal, classification policy, or evidence-transfer route.
Review boundary: Print or copy only the high-level prompts. Do not complete this sheet with credentials, customer records, private incident evidence, exploit payloads, or live target details.
ZERODEVLLC // FIRST BRIEF
Safe starting boundary: This review copy records a question and a possible next gate. It does not approve testing, accept evidence, establish certification, confirm clearance, or transfer responsibility for residual risk.
// INFORMATION HANDLING GUIDANCE
Use the least sensitive information needed to decide whether an engagement is appropriate. This is public engagement guidance, not a classification policy or a substitute for the applicable contract and authority.
| Information lane | Examples | First-contact rule | Next gate |
|---|---|---|---|
| High-level brief | Objective, sector, decision owner, outcome, and timeframe | Appropriate for an initial email when kept abstract and free of sensitive detail | Confirm the decision, authority, and scope |
| Sanitized or redacted example | Abstracted architecture, control summary, or redacted finding shape | Share only after the recipient, purpose, redaction, and retention boundary are agreed | Confirm evidence path and handling owner |
| Sensitive government or defense material | Controlled, contractual, classified, export-controlled, or otherwise restricted information | Do not send through ordinary email, public pages, or this public site | Establish an owner-approved exchange and handling process |
| Credentials, secrets, or live targets | Passwords, tokens, private keys, exploit payloads, or live target details | Never include in the initial brief or ordinary email | Use a separate authorized technical handoff only if necessary |
// CHOOSE THE DECISION
If the right service is not obvious, start with the decision rather than forcing the problem into a product name.
You need to understand exposure, weakness, risk, or technical condition.
Possible scope: Penetration testing, vulnerability assessment, technical due diligence, and cyber-risk review.
Review aligned services: Authorized penetration testing / Vulnerability assessment / Technical due diligence / Cyber risk management
You need evidence about controls, suppliers, readiness, or a decision boundary.
Possible scope: Vendor due diligence, compliance readiness, framework mapping, and assurance reporting.
Review aligned services: Vendor due diligence / Compliance readiness / Cyber risk management
You need to know whether critical work can continue and recover under pressure.
Possible scope: Incident readiness, disaster recovery, BCP, tabletop exercises, and recovery validation.
Review aligned services: Disaster recovery and BCP / Incident readiness / Cyber risk management
// WHAT HAPPENS NEXT
A response should make the next decision easier, even when the right answer is to narrow the scope, involve another owner, or stop.
Clarify the decision, service lane, stakeholders, and desired output.
Confirm that the proposed work is authorized, bounded, and safe to discuss.
Identify the minimum evidence needed and a safer exchange path if sensitive material is required.
Call out assumptions, exclusions, provider dependencies, and owner decisions.
Return a proportionate next step, including a no-fit answer when the work is not appropriate.
// INFORMATION BOUNDARY
Do not send passwords, tokens, private keys, customer records, payment details, malware, exploit payloads, private incident evidence, or unredacted system inventories through ordinary email. Do not request activity against a system you do not own or have written authority to test. Start with a high-level problem statement and the relevant decision owner.
Read the privacy boundary and controlled engagement methodology before sharing anything more specific.
// NEXT MOVE
Send only a high-level objective, the service question, the intended audience, and the person who can confirm authority. No sensitive evidence is required to start.
Start with the brief template
Review all services
Review deliverable shapes