| Definition | Name the information, service, system capability, people, or business mission that needs protection. Scope the fictional environment without identifying a live target. | Translate the protected asset into a needed security condition such as confidentiality, integrity, availability, authenticity, or accountability. | Describe at a high level how an adverse event could affect the security objective, using a category rather than an operational playbook. | Identify the weakness, dependency, process gap, or exposure condition that allows the threat mechanism to matter. | Explain the consequence if the threat mechanism acts through the exposure and affects the protected objective. | State what defensive change should occur: prevent an event, reduce exposure, detect it sooner, contain impact, recover capability, or compensate for a limitation. | Choose a suitable administrative, technical, or physical family and a preventive, detective, corrective, or compensating function. | Test whether the candidate interrupts the relevant path and state where it can fail, be bypassed, lose coverage, or create operational tradeoffs. | Describe the meaningful risk that remains after the safeguard changes likelihood, impact, detectability, or recovery. | Choose indicators that show whether the safeguard operates, covers the intended scope, and remains appropriate as conditions change. | Combine the claim, evidence, control rationale, limitations, residual risk, and monitoring plan into a bounded recommendation. |
|---|
| Primary decision question | What must continue to work, remain trustworthy, or remain appropriately confidential? | Which property must be preserved for the asset to support its mission? | What type of event could compromise the objective, and through what general path? | What condition creates the opportunity for harm? | What mission, operational, financial, legal, safety, or trust consequence could follow? | What must the safeguard accomplish against this mechanism or consequence? | Which type of safeguard can meet the stated objective in this context? | How does the safeguard change the scenario, and what does it leave untouched? | What credible event or consequence still remains, and is it acceptable or in need of another response? | What evidence would reveal control failure, drift, changed exposure, or a need to revise the response? | Why is this response proportionate and preferable under the stated assumptions? |
|---|
| Purpose | Gives the security argument a concrete object and prevents a list of controls from floating free of a mission. | Connects business importance to a measurable defensive aim. | Makes control selection responsive to a credible mechanism instead of a broad label. | Separates the source or mechanism of harm from the condition that makes the asset susceptible. | Provides the consequence side of risk reasoning and helps prioritize safeguards. | Creates a testable bridge between risk and control family. | Turns the desired outcome into a defensible category of response. | Prevents control-name matching from becoming an unsupported recommendation. | Keeps uncertainty and remaining exposure visible after mitigation. | Makes the recommendation maintainable instead of a one-time purchase. | Produces a reasoned security decision rather than a catalog of terms. |
|---|
| Time horizon | Current operating need and the period in which harm would matter. | The operating window in which the property must be maintained or restored. | The conditions and exposure period in which the event is plausible. | How long the fictional weakness or exposure persists before correction or reassessment. | Immediate disruption, recovery period, and plausible longer-term consequence. | Before, during, and after the fictional event as appropriate. | Implementation period plus ongoing operation and maintenance. | Normal operations, degraded operations, maintenance windows, and change over time. | The period after implementation until the next reassessment or material change. | Continuous or scheduled review based on the fictional risk and control. | Decision, implementation, review, and adjustment points. |
|---|
| Typical information | Fictional asset description, mission dependency, data sensitivity, availability need, and authorized stakeholder priorities. | Impact tolerance, authorized access expectations, data-quality needs, recovery expectations, and decision constraints. | Threat category, fictional event narrative, relevant capability assumptions, and primary-source defensive guidance. | Invented process gaps, configuration categories, governance gaps, training needs, or dependency assumptions. | Fictional impact ranges, downtime assumptions, decision dependencies, and stated uncertainty. | Desired outcome, timing, coverage, responsible role, and success measure. | Coverage, feasibility, dependencies, user impact, cost, skills, and compatibility with existing layers. | Fictional coverage map, assumptions, dependencies, failure modes, false-positive costs, and usability effects. | Remaining scenarios, control limitations, uncertainty, dependencies, and risk-owner tolerance. | Coverage indicators, exception trends, review results, response timing, change events, and ownership. | The preceding matrix stages, tradeoffs, alternatives, owner decision, and reassessment trigger. |
|---|
| Common confusion | Treating every technology as equally critical or starting with a favorite product. | Naming all three CIA objectives without explaining which one drives the decision. | Calling the threat itself a vulnerability or describing an attack sequence in unnecessary detail. | Repeating the threat name instead of identifying the susceptible condition. | Using dramatic language without tying the effect to the protected asset. | Naming a tool before defining the objective it must meet. | Assuming a technical safeguard is always superior to governance, training, or physical controls. | Equating implementation with complete effectiveness. | Reporting residual risk as zero merely because a control exists. | Counting deployments instead of measuring effectiveness and remaining risk. | Presenting a safeguard as the conclusion without evidence, limitations, or follow-up. |
|---|
| What does not belong | Real credentials, live asset inventories, exploitable configurations, or organization-specific attack planning. | A generic statement that security should be strong without a defined objective. | Payloads, exploit commands, credential theft procedures, scanning instructions, or evasion techniques. | Live vulnerability details, proof-of-concept steps, target addresses, or weaponization guidance. | Claims about a real organization, guaranteed losses, or unsupported regulatory conclusions. | Vendor promotion, unbounded claims, or a control objective unrelated to the identified path. | Configuration recipes or claims that one family addresses every threat. | Absolute claims such as eliminates all risk or cannot be bypassed. | A guarantee of safety, unsupported numeric precision, or a compliance attestation. | Live monitoring procedures against systems without authorization. | A completed security plan for submission or instructions for offensive activity. |
|---|