[
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's VoIP phone system handles CUI discussions with the DoD but does not permanently store recordings. Under CMMC scoping guidance, this system is best classified as:",
    "opts": [
      "Out of Scope — phones aren't IT systems",
      "Contractor Risk Managed Asset (CRMA)",
      "Specialized Asset",
      "CUI Asset requiring full protection"
    ],
    "ans": 1,
    "compliment": "CRMA ROYALTY! You magnificent scoping oracle — the assessment gods bow to you!",
    "praise": "CRMA nailed! VoIP handling CUI discussions can touch CUI but when the OSC manages that risk without formal CUI asset controls, it's a CRMA. Your scoping instincts are honed like a laser. Lesser assessors would have panicked and put this in the CUI Asset bucket. Not you.",
    "burn": "What's the matter with you? Have you been posing as an assessor this entire time?",
    "roast": "VoIP that carries CUI conversations is a CRMA — the OSC handles it but it can touch CUI. 'I manage the risk' is not a scoping methodology."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC has a legacy manufacturing control system (OT/ICS) on a fully isolated network that has never touched CUI or systems that handle CUI. How should this system be scoped?",
    "opts": [
      "Out of Scope entirely",
      "Specialized Asset — assessed with tailored practices",
      "In-scope CUI Asset — all OT is automatically in scope",
      "CRMA — risk managed by the OSC"
    ],
    "ans": 1,
    "compliment": "Specialized Asset SAVANT! You've clearly read Appendix B until it begged for mercy!",
    "praise": "Specialized Asset! Isolated OT/ICS that never touches CUI is a Specialized Asset — still in the assessment boundary but with tailored practices. Not a CUI Asset, not fully out of scope. You drew the line with precision that would make a DIBCAC auditor weep with pride.",
    "burn": "You just auto-scoped an isolated toaster as a CUI Asset. Outstanding work.",
    "roast": "An isolated OT system with zero CUI involvement is a Specialized Asset — in scope but assessed differently, not a CUI Asset. Zero CUI means zero CUI Asset classification."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's cloud email system (Microsoft 365 GCC) receives, stores, and transmits CUI in email attachments. How should this system be classified?",
    "opts": [
      "CUI Asset — it stores and transmits CUI",
      "CRMA — Microsoft manages the security",
      "Security Protection Asset",
      "Out of Scope — it's a commercial cloud product"
    ],
    "ans": 0,
    "compliment": "CUI ASSET DETECTOR! You identified that email system without breaking a sweat!",
    "praise": "CUI Asset! If the email system stores and transmits CUI, it is absolutely a CUI Asset regardless of whether it's cloud-hosted or commercial. The vendor's security controls inform your assessment but they don't reclassify the asset. You knew that. That's experience talking.",
    "burn": "It stores and transmits CUI and you said Out of Scope. Microsoft would like a word.",
    "roast": "An email system that stores and transmits CUI is a CUI Asset — commercial licensing is not a scoping exemption. The data determines the classification."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "A shared office printer in the general workspace occasionally prints CUI documents sent by employees. This printer is best classified as:",
    "opts": [
      "CUI Asset — it processes CUI",
      "Out of Scope — it's just a printer",
      "Specialized Asset — physical device",
      "CRMA — employees manage the print jobs"
    ],
    "ans": 0,
    "compliment": "PRINTER PROPHET! You assessed that output device with ruthless accuracy!",
    "praise": "CUI Asset! A printer that processes CUI documents — receiving, spooling, printing — is a CUI Asset. It processes CUI. That is the definition. Printers have hard drives, buffer memory, and network interfaces. You know this. You passed.",
    "burn": "It's just a printer. That stores CUI in its spool buffer. On its hard drive. On your network. But sure, Out of Scope.",
    "roast": "A networked printer that processes CUI documents stores data internally and is in scope. 'Just a printer' is what people say right before a finding."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's HR system manages employee records, payroll, and benefits. It has no connectivity to CUI systems and no access to CUI. How is it scoped?",
    "opts": [
      "CUI Asset — HR data is sensitive",
      "Out of Scope",
      "Security Protection Asset",
      "CRMA — HR manages the risk"
    ],
    "ans": 1,
    "compliment": "OUT-OF-SCOPE SURGEON! Clean cut, no collateral damage, absolutely correct!",
    "praise": "Out of Scope! No CUI access, no path to CUI, no security function for CUI systems — the HR system is out of the assessment boundary entirely. You didn't over-scope it just because it holds sensitive data. Sensitivity doesn't equal CUI. That distinction is everything.",
    "burn": "HR data is sensitive but it is not CUI and this system is not in scope. These are different things.",
    "roast": "Sensitive business data is not CUI unless it meets DoD CUI Registry criteria. No CUI, no path to CUI, no security function — Out of Scope."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "A network firewall that controls traffic flow between the internet and the OSC's CUI environment is classified as:",
    "opts": [
      "CRMA",
      "CUI Asset — it touches all CUI traffic",
      "Security Protection Asset",
      "Out of Scope — it's infrastructure"
    ],
    "ans": 2,
    "compliment": "FIREWALL WHISPERER! You didn't even flinch — Security Protection Asset, clean and fast!",
    "praise": "Security Protection Asset! Firewalls, IDS/IPS, and similar security controls that protect CUI systems without themselves storing CUI are Security Protection Assets. They perform a critical security function. They are absolutely in scope. You knew this without hesitation.",
    "burn": "The firewall that protects your entire CUI environment is Out of Scope. Remarkable.",
    "roast": "A firewall controlling CUI network traffic is a Security Protection Asset — it performs the security function of controlling access to the CUI environment. If it's compromised, the boundary is gone."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "A contractor's personal home laptop, used exclusively for non-work personal use, with no OSC-installed software and no access to OSC systems — how is it scoped?",
    "opts": [
      "Specialized Asset — personally owned",
      "Out of Scope — no connection to OSC systems",
      "CUI Asset — contractor owns it",
      "CRMA — contractor manages the risk"
    ],
    "ans": 1,
    "compliment": "PERSONAL DEVICE PRECISION! You resisted the urge to over-scope and you were RIGHT!",
    "praise": "Out of Scope! A personal device with no access to OSC systems, no OSC software, and no path to CUI has zero relationship to the assessment boundary. You didn't panic and scope the employee's Netflix machine. That restraint keeps scope documents readable and assessments sane.",
    "burn": "The employee's personal laptop they use to watch Netflix is a CUI Asset to you. Noted.",
    "roast": "A personal device with zero CUI, zero connection to CUI systems, and zero security function for the CUI environment is Out of Scope. Ownership alone doesn't create scope — CUI does."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "Under CMMC scoping, what is the DEFINING characteristic that makes a system a 'CUI Asset'?",
    "opts": [
      "It runs on the OSC's network",
      "It is owned by the OSC",
      "It stores, processes, or transmits CUI",
      "It is connected to the internet"
    ],
    "ans": 2,
    "compliment": "DEFINITION DOMINATOR! You know the CUI Asset definition cold — that's foundational mastery!",
    "praise": "Stores, processes, or transmits CUI — that's the defining characteristic. Ownership, connectivity, and network presence are irrelevant without that data element. You went straight to the correct definition without getting distracted by the noise options. That's assessment clarity.",
    "burn": "Ownership determines CUI Asset status? Renting a server full of CUI makes it not a CUI Asset? Innovative.",
    "roast": "Network presence is not a CUI classification criterion — CUI contact is. A scheduling workstation on the corporate network with zero CUI and zero CUI path is Out of Scope."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "A DNS server used exclusively by the OSC's CUI environment to resolve internal hostnames is best classified as:",
    "opts": [
      "CUI Asset — it supports CUI operations",
      "CRMA",
      "Out of Scope — DNS is infrastructure",
      "Security Protection Asset"
    ],
    "ans": 3,
    "compliment": "DNS DOMAIN DETECTIVE! Infrastructure scoping done with absolute precision!",
    "praise": "Security Protection Asset! DNS supporting the CUI environment performs a security function — name resolution for CUI systems is a foundational network service. Compromise DNS and you can redirect CUI users anywhere. It's in scope as a Security Protection Asset. You didn't dismiss it as 'just infrastructure.'",
    "burn": "DNS is just infrastructure so it's Out of Scope. DNS hijacking is just a theory anyway.",
    "roast": "DNS infrastructure serving the CUI environment performs a security function — Security Protection Asset. 'Just infrastructure' is exactly what an attacker compromises first."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 2,
    "q": "What is the PRIMARY purpose of the CMMC scoping process for a Level 2 assessment?",
    "opts": [
      "To identify which assets, people, and technologies are subject to the CMMC practices",
      "To count how many systems the OSC owns",
      "To list every device connected to the internet",
      "To determine the OSC's annual cybersecurity budget"
    ],
    "ans": 0,
    "compliment": "YES. The entire point. You may proceed.",
    "praise": "The scoping process identifies which assets, personnel, technologies, and facilities fall within the CMMC assessment boundary. Without a defined boundary you cannot assess anything — you'd be chasing everything. Scoping is the bedrock of a credible, defensible assessment.",
    "burn": "You just described an asset inventory. Scoping is about the assessment boundary. Different document.",
    "roast": "Scoping defines the assessment boundary — which assets handle CUI and which protect it. Counting everything owned is an inventory. Knowing what's in scope is the job."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 2,
    "q": "Which CMMC document defines the five asset categories used during scoping?",
    "opts": [
      "32 CFR Part 170",
      "NIST SP 800-171 Appendix D",
      "The CMMC Assessment Process (CAP)",
      "The CMMC Scoping Guidance / Assessment Scope document"
    ],
    "ans": 3,
    "compliment": "DOCUMENT LITERACY CONFIRMED. Someone actually read the Scoping Appendix.",
    "praise": "The CMMC Scoping Guidance document (published by the CYBER-AB) defines the five asset categories: CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, and Out-of-Scope Assets. NIST 800-171 defines the practices. 32 CFR 170 defines the program. The Scoping document defines the boundary.",
    "burn": "Appendix D is a mapping table. It has never defined a scoping category. Not once.",
    "roast": "The CMMC Scoping Guidance defines the five asset categories — not NIST 800-171 Appendix D, which is a control mapping table. Know which document does what."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 2,
    "q": "A standalone printer in the CEO's office has never printed a CUI document and has no network connection to CUI systems. It should be classified as:",
    "opts": [
      "Out of Scope — no CUI, no path to CUI environment",
      "CRMA — the CEO manages the risk",
      "Security Protection Asset — it controls physical output",
      "CUI Asset — all printers can print CUI"
    ],
    "ans": 0,
    "compliment": "RESTRAINT. RARE. APPRECIATED. You did not scope the printer. The printer is fine.",
    "praise": "Out of Scope. No CUI ever processed, no network path to CUI systems, no security function for CUI. This is exactly what Out-of-Scope Assets look like — equipment that simply has no connection to the CUI environment whatsoever. Don't scope things just because they exist.",
    "burn": "By this logic, the parking lot is also in scope because cars could theoretically transport a CUI document.",
    "roast": "Scoping by anxiety — 'what if it prints CUI someday' — is not a methodology. Present state determines scope: no CUI, no path, no function equals Out of Scope."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 2,
    "q": "The CUI Environment (CUI-E) is best described as:",
    "opts": [
      "All systems owned by the prime contractor",
      "The entire corporate network of the OSC",
      "Any facility where DoD employees work",
      "The set of assets that store, process, or transmit CUI and the systems that protect them"
    ],
    "ans": 3,
    "compliment": "CUI-E LOCKED. You know where the fence is. Now let's see if you can build one.",
    "praise": "The CUI Environment comprises CUI Assets and Security Protection Assets — the systems that handle CUI and the systems that protect them. It does not include every device on the corporate network, every facility, or every system owned by the prime. The boundary follows the data and its protective infrastructure.",
    "burn": "You just scoped the entire company. Hope you have a big assessment team.",
    "roast": "The CUI Environment is CUI Assets plus Security Protection Assets — not the entire corporate network. Defining it as everything the OSC owns turns every assessment into an enterprise IT audit."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's file server stores both CUI project files and non-CUI HR documents in separate folders. This server is classified as:",
    "opts": [
      "CRMA — the OSC segments the data with folder permissions",
      "A CUI Asset — it stores CUI",
      "Two separate assets — one in scope, one out",
      "Out of Scope — non-CUI data is also present"
    ],
    "ans": 1,
    "compliment": "ONE SERVER. ONE ANSWER. You didn't get distracted by the HR folder. Impressive.",
    "praise": "CUI Asset. The presence of non-CUI data does not change the classification — the server stores CUI, so it is a CUI Asset. The entire server falls within the assessment boundary. You can't split a single system into partial scope based on folder structure alone.",
    "burn": "Folder permissions are not a scoping methodology. That's not a thing.",
    "roast": "One server with CUI in any folder is one CUI Asset in scope — the whole server. Schema and folder separation is not physical separation."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC uses a cloud-hosted collaboration platform (Teams/Slack) to discuss CUI project details with DoD personnel. The platform is classified as:",
    "opts": [
      "Security Protection Asset — it secures communications",
      "CRMA — Microsoft/Slack manages security",
      "Out of Scope — it's a commercial product",
      "CUI Asset — CUI is transmitted through it"
    ],
    "ans": 3,
    "compliment": "CUI IN THE CHAT. IN SCOPE. Done. You didn't need a second read on that one.",
    "praise": "CUI Asset. When CUI is transmitted through a cloud platform, that platform becomes a CUI Asset regardless of whether it's a commercial product or a third-party service. The 'commercial product' label does not create a scoping exemption. The data determines the classification.",
    "burn": "CUI transmitted through a commercial product is still CUI. The licensing agreement does not change this.",
    "roast": "Commercial licensing is not a CUI Asset exemption. A Teams channel full of CUI project discussions is a CUI Asset regardless of what Microsoft charges per seat."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's endpoint detection and response (EDR) solution monitors all workstations including those in the CUI environment. It is classified as:",
    "opts": [
      "CUI Asset — it accesses data on CUI systems",
      "Security Protection Asset",
      "Out of Scope — it's a security tool, not a CUI system",
      "CRMA — vendor manages the security function"
    ],
    "ans": 1,
    "compliment": "EDR = SPA. You saw it without hesitation. Your threat model is showing, in the best way.",
    "praise": "Security Protection Asset. An EDR solution that monitors CUI endpoints performs a security function for the CUI environment — it detects threats, collects security telemetry, and responds to incidents on CUI systems. Compromise the EDR and you blind or subvert the security monitoring of the entire CUI environment. Firmly in scope as an SPA.",
    "burn": "The attacker who owns your EDR owns your visibility into every CUI endpoint. Still think it's out of scope?",
    "roast": "SPAs exist precisely for security tools that protect the CUI environment without storing CUI themselves. An EDR monitoring CUI endpoints is the definition of an SPA."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's network switch exclusively serves the CUI enclave — all CUI traffic passes through it. It is classified as:",
    "opts": [
      "Security Protection Asset",
      "CUI Asset — CUI traverses it",
      "Specialized Asset",
      "Out of Scope — switches are just infrastructure"
    ],
    "ans": 0,
    "compliment": "'JUST A SWITCH' NOTHING. You correctly refused to ignore the thing carrying all the CUI traffic.",
    "praise": "Security Protection Asset. A network switch exclusively serving the CUI enclave is a Security Protection Asset — it enables and controls CUI network communications. Compromise this switch and you control all traffic in the CUI environment. 'Just infrastructure' is the most dangerous phrase in network security.",
    "burn": "'Just a switch' carrying all CUI traffic. The threat actor who owns it controls all CUI traffic. Just saying.",
    "roast": "A switch exclusively serving the CUI enclave is a Security Protection Asset — it enables and controls all CUI communications. 'Just a switch' is how air gaps get defeated."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's IT admin uses a personal laptop at home to connect via VPN to manage CUI servers after hours. The personal laptop is classified as:",
    "opts": [
      "Specialized Asset — non-standard endpoint",
      "CUI Asset — it accesses CUI systems",
      "Out of Scope — personally owned device",
      "CRMA — OSC accepts the personal device risk"
    ],
    "ans": 3,
    "compliment": "CRMA. CORRECT. The VPN tunnel into the CUI environment from a personal laptop is not 'fine.'",
    "praise": "CRMA. A personal device used to access CUI systems via VPN falls under Contractor Risk Managed Assets — the OSC allows personal device use and accepts responsibility for managing that risk. It's not a full CUI Asset because the CUI isn't stored locally, but it's not Out of Scope either. The VPN endpoint is in scope. The personal router isn't.",
    "burn": "Personal ownership is not a scoping exemption. Especially when it has a VPN tunnel into your CUI servers.",
    "roast": "An admin's personal laptop used to VPN into CUI servers is a CRMA — ownership is irrelevant when the device is a gateway into the CUI environment. CUI access determines scope."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC has an air-gapped CUI network and a separate corporate network. An employee connects a USB drive used on both networks. The USB drive is classified as:",
    "opts": [
      "CUI Asset — it stores CUI",
      "Specialized Asset",
      "CRMA — portable media risk is OSC-managed",
      "Out of Scope — it's just portable storage"
    ],
    "ans": 0,
    "compliment": "THE THUMB DRIVE THAT DEFEATED AN AIR GAP. You caught it. The APT did not get past you today.",
    "praise": "CUI Asset. A USB drive carrying CUI data — even temporarily — is a CUI Asset. More critically, a USB drive bridging an air-gapped CUI network and a corporate network is a severe security gap and an in-scope finding. This is how air gaps get defeated in practice.",
    "burn": "Just a thumb drive. That defeated your air gap. No big deal.",
    "roast": "A USB drive that bridges an air-gapped CUI network and a corporate network is a CUI Asset and a significant finding. Air gaps fail at exactly the human layer."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "A secretary's workstation is used exclusively for scheduling, email, and word processing. She occasionally receives meeting invites that mention project names but never accesses CUI systems or files. Her workstation is:",
    "opts": [
      "Out of Scope",
      "Security Protection Asset — she controls access to the facility",
      "In scope as a CRMA",
      "CUI Asset — she receives CUI-adjacent emails"
    ],
    "ans": 0,
    "compliment": "YOU KEPT IT OUT. A meeting invite is not CUI. The scheduling assistant is not in scope. Thank you.",
    "praise": "Out of Scope. Meeting invites mentioning project names are not CUI. The workstation has no path to CUI systems and no security function for the CUI environment. Scoping it in because of email proximity to project names is over-scoping. CMMC follows actual CUI — not adjacency to people who work near CUI.",
    "burn": "A meeting invite with a project name. In scope. Your assessment just grew to include every inbox in the building.",
    "roast": "A scheduling workstation with no CUI access and no CUI path is Out of Scope. Scoping every device within email distance of CUI-adjacent information produces an unworkable assessment boundary."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's patch management server pushes updates to both CUI and non-CUI systems. It is classified as:",
    "opts": [
      "Out of Scope — it only pushes software",
      "Security Protection Asset",
      "CRMA — IT team manages patching risk",
      "CUI Asset — it connects to CUI systems"
    ],
    "ans": 1,
    "compliment": "PATCH SERVER = SPA. You remembered NotPetya so the OSC's CUI network wouldn't have to.",
    "praise": "Security Protection Asset. A patch management server that pushes updates to CUI systems performs a security function — maintaining the security posture of CUI assets. A compromised patch server is a powerful supply chain attack vector against CUI systems. In scope as an SPA.",
    "burn": "It only pushes software so it's Out of Scope? NotPetya called. It has thoughts on patch management security.",
    "roast": "A patch management server pushing updates to CUI systems maintains their security posture — Security Protection Asset. NotPetya was a patch mechanism compromise. In scope."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 2,
    "q": "Which of the following is definitively OUT OF SCOPE for a CMMC Level 2 assessment?",
    "opts": [
      "A server that processes CUI",
      "A workstation used for scheduling with no CUI access or path to CUI systems",
      "A firewall protecting the CUI network",
      "A cloud backup storing encrypted CUI"
    ],
    "ans": 1,
    "compliment": "CORRECTLY OUT OF SCOPE. You did not scope the coffee maker. A lesser assessor might have.",
    "praise": "The scheduling workstation with no CUI access and no path to CUI systems is definitively Out of Scope. The CUI server, the protective firewall, and the CUI cloud backup are all in scope under their respective categories. Out-of-Scope Assets are those with no CUI, no path to CUI, and no security function for CUI.",
    "burn": "The firewall protecting the CUI network is Out of Scope? The network architect would like a word.",
    "roast": "The scheduling workstation with no CUI connection is the only Out-of-Scope item here. The other three — CUI server, protective firewall, encrypted CUI backup — are all in scope under their respective categories."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's remote work policy allows employees to work from home on company-issued laptops via VPN. The laptops store CUI locally between sessions. These laptops are classified as:",
    "opts": [
      "CRMA — remote work risk is OSC-managed",
      "Specialized Assets — non-standard work environment",
      "Out of Scope — they're used at home",
      "CUI Assets"
    ],
    "ans": 3,
    "compliment": "REMOTE WORK CUI ASSET CONFIRMED! Local CUI storage seals the classification regardless of location!",
    "praise": "CUI Assets. Company-issued laptops that store CUI locally are CUI Assets — full stop. Location (home, office, coffee shop) does not change the data classification. These laptops carry full CUI Asset controls including encryption at rest, MFA for access, and all applicable NIST 800-171 practices.",
    "burn": "Used at home therefore Out of Scope? CUI doesn't become non-CUI when it crosses the front door threshold.",
    "roast": "A company laptop storing CUI is a CUI Asset whether it's in the office, at home, or in a hotel. Location changes the risk profile — not the classification."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's cybersecurity awareness training platform delivers mandatory annual training to all employees including those who never touch CUI. The platform itself contains no CUI. It is classified as:",
    "opts": [
      "CUI Asset — it trains CUI users",
      "Out of Scope — no CUI, no direct security function for CUI systems",
      "CRMA — HR manages training compliance",
      "Security Protection Asset — training supports security posture"
    ],
    "ans": 1,
    "compliment": "TRAINING PLATFORM SCOPE RESTRAINED! Security awareness training platform — correctly Out of Scope!",
    "praise": "Out of Scope. A training platform that contains no CUI and has no technical connection to CUI systems is Out of Scope. Security awareness training is a practice requirement — but the LMS delivering it doesn't become an SPA just because it supports a security practice. The security function performed by SPAs must be technical and direct — not administrative.",
    "burn": "By this logic, the compliance policy Word doc is also a Security Protection Asset. It is not.",
    "roast": "SPAs technically protect the CUI environment. An LMS delivering training is an administrative tool — it supports the human element of security but doesn't technically protect CUI systems. Out of Scope."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 2,
    "q": "A Specialized Asset in CMMC scoping is best described as:",
    "opts": [
      "An asset that may be in scope but is assessed using tailored practices due to its nature",
      "Any asset the OSC designates as special purpose",
      "A CUI Asset operated by a subcontractor",
      "An Out-of-Scope asset that receives enhanced monitoring"
    ],
    "ans": 0,
    "compliment": "SPECIALIZED ASSET DEFINED! Tailored assessment approach for in-scope special-purpose systems!",
    "praise": "Specialized Assets are systems that may be in scope but require tailored assessment practices due to their nature — OT/ICS, IoT devices, medical devices, test equipment, government-furnished equipment. They're not exempt from the assessment; the assessment approach is adapted to their technical characteristics.",
    "burn": "Specialized Assets are whatever the OSC designates? They'd designate everything. That's not how it works.",
    "roast": "Specialized Assets are in scope with tailored practices — OT, IoT, medical devices, test equipment. It's a defined category with defined criteria, not a self-declared exemption."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's CUI network has 47 endpoints. During scoping, the OSC presents a system security plan (SSP) covering only 30 of them, claiming the other 17 are 'administrative.' What should the assessor do?",
    "opts": [
      "Assess only the 30 systems documented in the SSP",
      "Report the discrepancy to the Contracting Officer immediately and halt the assessment",
      "Accept the SSP — the OSC defines their own boundary",
      "Investigate the 17 systems to determine if they belong in the CUI environment"
    ],
    "ans": 3,
    "compliment": "17 UNACCOUNTED SYSTEMS. You noticed. The OSC was hoping you wouldn't.",
    "praise": "Investigate the 17 systems. The assessor's job is to validate the scope, not just accept it. If 17 systems on the CUI network aren't in the SSP, the assessor must determine whether they're legitimately Out of Scope (and why) or whether they belong in the assessment boundary. 'Administrative' is not a defined asset category.",
    "burn": "Accept the SSP — the OSC defines their own boundary? The OSC can document whatever they want. Your job is to verify it.",
    "roast": "The assessor validates the proposed scope. Seventeen systems on the CUI network absent from the SSP requires investigation — 'administrative' is not a CMMC asset category."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC has decommissioned a CUI server. The drives were wiped using DoD-approved methods and the server was physically destroyed. Where does this system fall in the current scope?",
    "opts": [
      "Out of Scope — properly decommissioned systems exit the boundary",
      "CRMA — the disposal vendor manages remaining risk",
      "Must remain in scope for 3 years post-decommission per CMMC policy",
      "Still in scope — it once held CUI"
    ],
    "ans": 0,
    "compliment": "PROPERLY DESTROYED = OUT OF SCOPE. It's not haunted. It's done. Good.",
    "praise": "Out of Scope. A system that has been properly decommissioned — drives wiped to DoD standards and physically destroyed — is no longer in the CUI environment. Present state governs scope. Document the decommission process and media destruction records as evidence, but the system itself is no longer an in-scope asset.",
    "burn": "Three years post-decommission retention in scope? That's not CMMC policy. That's a policy you invented.",
    "roast": "Properly destroyed systems with documented DoD-standard sanitization exit the scope boundary. Verify the destruction records and move on."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 2,
    "q": "Which of the following best describes a 'Contractor Risk Managed Asset' (CRMA)?",
    "opts": [
      "A government-furnished asset managed by the contractor",
      "An asset that can process CUI but is managed by the contractor to limit that risk",
      "An out-of-scope asset that is monitored for risk",
      "A CUI Asset where the contractor has accepted full liability"
    ],
    "ans": 1,
    "compliment": "CRMA. CORRECT DEFINITION. Not liability acceptance. Not magic exemption. Managed risk. Yes.",
    "praise": "A CRMA is an asset that can process CUI but the contractor has implemented controls to manage and limit that risk — rather than applying full CUI Asset protections. Examples include personal devices used for MFA push notifications or printers that could theoretically print CUI but are managed to prevent unauthorized use. The OSC accepts and manages the residual risk.",
    "burn": "Liability acceptance is not an asset category. That is a legal concept wearing the wrong hat.",
    "roast": "CRMAs are in-scope assets where the OSC has documented and accepted residual risk rather than applying full CUI Asset protections. It's a deliberate risk management decision, not a liability category."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC's accounts payable system processes contractor invoices. None of the invoice data is CUI. The system has no connection to CUI systems. It is classified as:",
    "opts": [
      "CRMA — finance team manages the risk",
      "Out of Scope",
      "Security Protection Asset — financial systems protect business operations",
      "CUI Asset — financial data is always sensitive"
    ],
    "ans": 1,
    "compliment": "SENSITIVE ≠ CUI. Accounts payable is not your problem today. You knew the difference.",
    "praise": "Out of Scope. Accounts payable processing contractor invoices without CUI is not a CUI Asset. Sensitivity doesn't equal CUI — the CMMC boundary follows DoD-related Controlled Unclassified Information specifically. Business financial data processed in a system with no CUI and no path to CUI systems is outside the CMMC assessment boundary.",
    "burn": "Sensitive business data is not CUI. CMMC is not PCI-DSS. The accounts payable team is relieved.",
    "roast": "Accounts payable processing contractor invoices is sensitive business data but not CUI under the DoD CUI Registry. No CUI, no path to CUI, no security function — Out of Scope."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "Which NIST 800-171 practice family requires organizations to evaluate the security impact of a change before it is implemented?",
    "opts": [
      "Access Control (AC)",
      "Identification and Authentication (IA)",
      "Configuration Management (CM)",
      "Security Assessment (CA)"
    ],
    "ans": 2,
    "compliment": "CONFIGURATION MANAGEMENT MAESTRO! You analyzed that change before it ever touched production!",
    "praise": "Configuration Management CM.L2-3.4.4 – Security Impact Analysis requires organizations to analyze the security impact of changes before they are implemented. This analysis helps determine whether a proposed change could negatively affect the security posture of the environment, the effectiveness of existing security controls, system boundaries, data flows, or the protection of Controlled Unclassified Information (CUI).",
    "burn": "Know your Configuration Management family because ignorance isn't bliss.",
    "roast": "Reviewing the security impact of a proposed change is a critical component of an effective change management process. Organizations may incorporate this analysis into change request templates, change management systems, approval workflows, or documented administrative procedures.",
    "community": {
      "submitter": "Bobby Guerra",
      "date": "June 2, 2026",
      "avatar": "assets/community/bobby-guerra.jpeg"
    }
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "CMMC Level 1 is designed to protect which category of information?",
    "opts": [
      "Sensitive But Unclassified (SBU) data",
      "Classified National Security Information",
      "Controlled Unclassified Information (CUI)",
      "Federal Contract Information (FCI)"
    ],
    "ans": 3,
    "compliment": "FCI FUNDAMENTALS FLAWLESS! Level 1 basics mastered — you're already ahead of the curve!",
    "praise": "FCI! CMMC Level 1 protects Federal Contract Information using 17 practices mapped to FAR 52.204-21. Level 2 protects CUI. Level 3 is enhanced CUI. You know the levels cold. That's the foundation everything else is built on.",
    "burn": "Level 1 protects CUI? Level 1 is the FCI level. CUI is Level 2. This is introductory material.",
    "roast": "CMMC Level 1 protects Federal Contract Information using 17 FAR 52.204-21 practices. CUI is protected at Level 2 and above. This is slide one of every CMMC briefing."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "CMMC Level 2 maps directly to which NIST publication?",
    "opts": [
      "NIST SP 800-171 Rev 2",
      "NIST SP 800-37",
      "NIST SP 800-172",
      "NIST SP 800-53 Rev 5"
    ],
    "ans": 0,
    "compliment": "800-171 SOLDIER! The foundational mapping rattled off without hesitation — love to see it!",
    "praise": "NIST SP 800-171 Rev 2! All 110 practices in CMMC Level 2 map directly to 800-171 Rev 2. This is the core NIST publication for CUI protection in non-federal systems. You knew it without blinking.",
    "burn": "800-53 is for federal agencies, not the Defense Industrial Base. Different publication, different audience.",
    "roast": "CMMC Level 2 maps to NIST SP 800-171, which was specifically designed for nonfederal contractors. 800-53 is for federal agencies. Know which standard applies to whom."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "CMMC 2.0 Level 2 contains exactly how many practices?",
    "opts": [
      "110",
      "130",
      "17",
      "72"
    ],
    "ans": 0,
    "compliment": "110 LOCKED IN! You carry the practice count like a weapon and you used it perfectly!",
    "praise": "110 practices! CMMC Level 2 contains 110 practices, all mapped to NIST SP 800-171 Rev 2. Level 1 has 17, Level 3 adds more from NIST SP 800-172. The 110 number is foundational — you knew it without hesitation.",
    "burn": "72 practices? Where did 72 come from? That's not a CMMC level, that's a random number.",
    "roast": "It's 110. One hundred and ten. The most cited number in the entire program. Write it down."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Which DFARS clauses require contractors to implement NIST SP 800-171 AND submit a self-assessment score to SPRS?",
    "opts": [
      "DFARS 252.204-7019 and 7020",
      "DFARS 252.204-7012",
      "DFARS 252.239-7010",
      "DFARS 252.204-7021"
    ],
    "ans": 0,
    "compliment": "DFARS CITATION CHAMPION! You fired off those clause numbers like a Federal Register sommelier!",
    "praise": "7019 requires the self-assessment and 7020 requires SPRS submission. 7021 is the CMMC requirement clause. 7012 is cyber incident reporting. You separated them cleanly. That citation precision is what separates assessors from encyclopedia entries.",
    "burn": "7012 is the breach reporting clause. Not the SPRS submission clause. Very different obligations.",
    "roast": "DFARS 7019 requires the 800-171 assessment, 7020 requires posting to SPRS. DFARS 7012 is about cyber incident reporting. Three separate clauses with three separate obligations."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under 32 CFR Part 170, how long does an OSC have to close open POA&M items after receiving conditional Level 2 certification?",
    "opts": [
      "120 days",
      "90 days",
      "180 days",
      "365 days"
    ],
    "ans": 2,
    "compliment": "180 DAYS — REGULATORY CLOCK MASTER! You know the timeline like it's tattooed on your hand!",
    "praise": "180 days per 32 CFR Part 170. The OSC gets six months to close conditional POA&M items. You didn't guess 90, you didn't overthink and say 365 — you went straight to the rule. That's what reading the actual CFR looks like.",
    "burn": "90 days. That's a quarterly business review, not a POA&M remediation window.",
    "roast": "32 CFR Part 170 gives OSCs 180 days to achieve CMMC compliance after contract award, not 90. Telling an OSC half the actual timeframe creates real legal and operational harm."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under 32 CFR Part 170, which entity is responsible for verifying an OSC's CMMC status before awarding a contract requiring CMMC?",
    "opts": [
      "DCSA",
      "The CYBER-AB",
      "The C3PAO that performed the assessment",
      "The Contracting Officer (CO)"
    ],
    "ans": 3,
    "compliment": "CONTRACTING OFFICER CHAMPION! You understand the acquisition pipeline from start to finish!",
    "praise": "The Contracting Officer verifies CMMC status via SPRS and the CMMC database before award. C3PAOs certify, the CYBER-AB accredits, DCSA governs — but the CO pulls the contract trigger. You understand how the whole machine works together. That's enterprise-level program awareness.",
    "burn": "C3PAOs certify assessments. They do not award government contracts. Very different roles.",
    "roast": "Contract award authority belongs to the Contracting Officer with warrant authority. C3PAOs assess and certify — they have no role in acquisition decisions."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "A contractor's SPRS score for NIST SP 800-171 self-assessment can range from what to what?",
    "opts": [
      "0 to 110",
      "–110 to 110",
      "0 to 100",
      "–203 to 110"
    ],
    "ans": 3,
    "compliment": "SPRS SCORE SAVANT! Negative 203 to 110 — you knew the full range without hesitation!",
    "praise": "–203 to 110! The SPRS score starts at 110 (perfect) and each unimplemented practice deducts points weighted by practice value. The minimum possible score is –203. A score of 110 means all practices are implemented. You know the scoring mechanics cold.",
    "burn": "0 to 110? A perfect self-assessment gives 110. A terrible one can hit negative 203. It goes negative.",
    "roast": "SPRS scoring starts at 110 and deducts for each unimplemented practice, weighted by impact. The score can go negative. Zero controls is not a zero score."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Which DFARS clause specifically requires contractors to have and maintain a CMMC certification as a condition of contract performance?",
    "opts": [
      "DFARS 252.204-7021",
      "DFARS 252.204-7012",
      "DFARS 252.204-7020",
      "DFARS 252.204-7019"
    ],
    "ans": 0,
    "compliment": "7021 SHARP-SHOOTER! You went straight to the CMMC contract clause without blinking!",
    "praise": "DFARS 252.204-7021 is the CMMC requirement clause — it mandates that contractors achieve and maintain the specified CMMC level as a condition of contract award and performance. 7012 is incident reporting, 7019 is the self-assessment requirement, 7020 is the SPRS submission. You know each clause's purpose cold.",
    "burn": "7012 is the incident reporting clause. Not the CMMC certification requirement. Two entirely different obligations.",
    "roast": "The CMMC certification requirement lives in DFARS 7021. DFARS 7012 governs cyber incident reporting. Two entirely different obligations under two entirely different clauses."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "CUI categories and subcategories are defined and managed by which entity?",
    "opts": [
      "NIST through its SP 800-171 publication",
      "Contracting Officers in each individual contract",
      "National Archives and Records Administration (NARA)",
      "Department of Defense (DoD)"
    ],
    "ans": 2,
    "compliment": "NARA NAVIGATOR! You know who runs the CUI Registry and you went straight to the source!",
    "praise": "NARA manages the CUI Registry, which defines all CUI categories and subcategories. The DoD uses and applies CUI designations but NARA is the authoritative source for what constitutes CUI. Understanding this separation is important when OSCs push back on what qualifies as CUI.",
    "burn": "DoD defines CUI? DoD applies CUI designations but NARA manages the actual CUI Registry.",
    "roast": "NARA manages the CUI Registry and defines all CUI categories and subcategories. DoD applies and handles CUI — NARA is the authoritative source for what constitutes it."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Which publication or regulation serves as the source for the 17 Level 1 practices in CMMC?",
    "opts": [
      "NIST SP 800-171 Rev 2",
      "NIST SP 800-53 Rev 5",
      "DFARS 252.204-7012",
      "FAR 52.204-21"
    ],
    "ans": 3,
    "compliment": "FAR 52.204-21 SCHOLAR! Level 1 sourcing from the federal acquisition regulation — nailed it!",
    "praise": "FAR 52.204-21 is the Federal Acquisition Regulation clause for basic safeguarding of covered contractor information systems — and its 15 requirements (plus 2 additional) form the basis of CMMC Level 1's 17 practices. You went to the regulatory source. That's precision.",
    "burn": "800-171 has 110 requirements. Level 1 has 17 practices. Those 17 come from FAR 52.204-21.",
    "roast": "CMMC Level 1's 17 practices come from FAR 52.204-21 — the basic safeguarding requirements for FCI. 800-171's 110 practices are Level 2. Different standard, different level."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "What does the 'M' in CMMC stand for?",
    "opts": [
      "Mandatory",
      "Maturity",
      "Monitoring",
      "Management"
    ],
    "ans": 1,
    "compliment": "ACRONYM ACE! Cybersecurity Maturity Model Certification — you didn't even blink!",
    "praise": "Maturity! Cybersecurity Maturity Model Certification — the 'maturity' model component was originally more prominent in CMMC 1.0 with its five maturity levels. CMMC 2.0 streamlined to three levels but retained the maturity framework concept. You know your program name.",
    "burn": "CMMC stands for Cybersecurity Mandatory Model Certification? 'Mandatory' is M4 in that sentence. It's Maturity.",
    "roast": "CMMC stands for Cybersecurity Maturity Model Certification. The M is Maturity — the maturity model concept is the program's foundational framework. Yes, it's also mandatory. That's a different M."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "DFARS clause 252.204-7012 requires contractors to implement which security standard?",
    "opts": [
      "NIST SP 800-171",
      "NIST SP 800-53",
      "ISO 27001",
      "FedRAMP Moderate"
    ],
    "ans": 0,
    "vars": [
      {
        "q": "A company sells standard off-the-shelf software to the DoD. The software is unmodified commercial code. The contract includes DFARS 252.204-7012 as a standard clause. Are the 800-171 implementation requirements triggered?",
        "opts": [
          "Yes — the clause is in the contract",
          "No — DFARS 252.204-7012 does not apply to contracts solely for COTS items; clause presence does not trigger security requirements for pure COTS sales",
          "Yes — all software sold to DoD requires 800-171 regardless of modification status",
          "Depends on whether the software has a government-customized version"
        ],
        "ans": 1
      }
    ],
    "compliment": "DFARS → 800-171. You didn't say 800-53. We can continue.",
    "praise": "NIST SP 800-171, Protecting CUI in Nonfederal Information Systems and Organizations, is the security standard required by DFARS 252.204-7012. NIST 800-53 is for federal information systems. ISO 27001 is an international standard. FedRAMP Moderate applies when using cloud service providers.",
    "burn": "DFARS 7012 requires NIST 800-53? 800-53 is for federal systems. Contractors implement 800-171.",
    "roast": "DFARS 252.204-7012 requires nonfederal contractors to implement NIST SP 800-171 — specifically designed for nonfederal systems. 800-53 is for federal agencies. Wrong standard, wrong audience."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "Under DFARS 252.204-7012, within how many hours must a contractor report a cyber incident to DoD after discovery?",
    "opts": [
      "24 hours",
      "72 hours",
      "48 hours",
      "7 days"
    ],
    "ans": 1,
    "compliment": "72 HOURS FROM DISCOVERY. Not 'after the investigation.' Not 'when we figure it out.' 72 hours.",
    "praise": "72 hours. DFARS 252.204-7012 requires contractors to report cyber incidents within 72 hours of discovery — not detection, not investigation, not determination of impact. Discovery triggers the clock. Partial information can be submitted initially with a follow-on report as more becomes available.",
    "burn": "Seven days. An adversary can exfiltrate everything in seven days. That is precisely why the requirement is 72 hours.",
    "roast": "72 hours from discovery — not from investigation completion, not from impact determination. Discovery starts the clock. Report what you have; submit follow-ons as more becomes available."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "What is the purpose of the Supplier Performance Risk System (SPRS)?",
    "opts": [
      "To manage DoD's classified contractor relationships",
      "To store CMMC Level 3 assessment results only",
      "To issue CMMC certificates to certified organizations",
      "To serve as DoD's authoritative source for supplier performance and cybersecurity assessment results"
    ],
    "ans": 3,
    "compliment": "SPRS: AUTHORITATIVE SOURCE. Not a certificate printer. Not a trophy case. A database DoD actually checks.",
    "praise": "SPRS is the DoD's authoritative source for supplier performance information including NIST SP 800-171 DoD Assessment results. Contractors self-submit Basic assessment scores and DoD posts Medium and High assessment results. Contracting officers consult SPRS before awarding contracts and making risk decisions.",
    "burn": "SPRS issues CMMC certificates? SPRS is a database. Certificates come from C3PAOs and the CYBER-AB.",
    "roast": "SPRS stores supplier performance data including cybersecurity assessment scores. Contracting officers check SPRS before award. Certificates come from C3PAOs — not SPRS."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "A contractor submits a self-assessed NIST SP 800-171 score of 110 to SPRS but has knowingly unimplemented requirements. Which law creates potential criminal liability?",
    "opts": [
      "The False Claims Act (31 U.S.C. §§ 3729-3733)",
      "DFARS 252.204-7012 directly",
      "The Federal Acquisition Regulation (FAR)",
      "NIST SP 800-171 itself"
    ],
    "ans": 0,
    "compliment": "THE FCA. The reason a bad SPRS score isn't just a paperwork problem. You found the teeth.",
    "praise": "The False Claims Act. A contractor who knowingly submits a false SPRS score to obtain a government contract may face civil and criminal liability under the FCA. DoJ has pursued FCA cases specifically against defense contractors for cybersecurity fraud. NIST 800-171 and DFARS create the obligation — the FCA creates the enforcement teeth.",
    "burn": "DFARS 252.204-7012 itself creates criminal liability? DFARS is a contracting regulation, not a criminal statute.",
    "roast": "The False Claims Act creates civil and criminal liability for knowingly false compliance representations to the government. DFARS creates the obligation — the FCA provides the enforcement teeth."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "A contractor outsources all IT to a Managed Service Provider (MSP). Under DFARS 252.204-7012, who is responsible for compliance?",
    "opts": [
      "The MSP — they operate the systems",
      "DoD — they approved the MSP arrangement",
      "The contractor — outsourcing does not transfer contractual obligations",
      "Both equally — shared responsibility"
    ],
    "ans": 2,
    "compliment": "OUTSOURCING THE IT ≠ OUTSOURCING THE OBLIGATION. You knew which one stays with the contract signer.",
    "praise": "The contractor. DFARS FAQ Q7 is explicit: outsourcing IT to a third party does not transfer DFARS 252.204-7012 responsibilities. The contractor who signed the government contract is accountable. The key is having a well-written agreement with the MSP that includes deliverables meeting CMMC requirements — but ultimate accountability stays with the prime.",
    "burn": "The government contracted with you. Not your MSP. The obligation did not forward to their inbox.",
    "roast": "DFARS FAQ Q7 is one sentence: outsourcing IT does not transfer your DFARS 252.204-7012 responsibilities. The OSC who signed the DoD contract is accountable."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Malware is launched in a commercial sandbox/detonation chamber and successfully contained. Why is this NOT a reportable cyber incident under DFARS 252.204-7012?",
    "opts": [
      "Only nation-state malware requires reporting",
      "Sandboxes are Out of Scope for DFARS reporting",
      "The protections worked as designed — no adverse effect occurred",
      "Malware in sandboxes doesn't count because it's small"
    ],
    "ans": 2,
    "compliment": "SANDBOX CONTAINED IT. NOT REPORTABLE. The protections worked. You understood what that means.",
    "praise": "FAQ Q41 is clear: if the sandbox successfully contained the malware, the protections worked as designed and there was no actual or potentially adverse effect. No reportable cyber incident occurred. Compare to Q40 — malware that bypasses AV and installs on a CUI system IS reportable because there is a potentially adverse effect.",
    "burn": "Sandbox malware isn't reportable because it's small? Size is not a criterion in cyber incident reporting. Effect is.",
    "roast": "A sandbox that successfully contained malware had no adverse effect — the protection worked. FAQ Q41 is explicit: that's not a reportable incident. FAQ Q40 covers the other side: bypassed AV is reportable."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "A contractor suffers a cyber incident but cannot gather all required reporting information within 72 hours. What should they do?",
    "opts": [
      "Only report if more than 50% of required fields can be completed",
      "Wait until all information is available before reporting",
      "Submit whatever information is available and file a follow-on report",
      "Request a 72-hour extension from the Contracting Officer"
    ],
    "ans": 2,
    "vars": [
      {
        "q": "An OSC discovers ransomware on a CUI server at 6 PM Friday. Their forensic vendor can't start work until Monday. When must the OSC report to DoD?",
        "opts": [
          "Monday when the investigation begins",
          "Within 72 hours of Friday evening discovery — investigation status does not pause the clock",
          "After confirming CUI exfiltration",
          "When the Contracting Officer is notified"
        ],
        "ans": 1
      },
      {
        "q": "A contractor detects unusual network traffic at 2 AM that suggests a possible intrusion into a CUI system. The security team is investigating but has little information yet. Under DFARS, they should:",
        "opts": [
          "Wait until they have a complete picture before reporting",
          "Report via DC3 within 72 hours of discovery with whatever information is available, filing follow-on reports as more becomes known",
          "Contact the Contracting Officer first and report to DoD only after CO guidance",
          "Report only if exfiltration of CUI is confirmed"
        ],
        "ans": 1
      }
    ],
    "compliment": "SUBMIT WHAT YOU HAVE. FOLLOW-ON LATER. The 72-hour clock doesn't care about your investigation timeline.",
    "praise": "FAQ Q44 directs contractors to submit whatever information is available within 72 hours via DC3 and then submit a follow-on report when additional information becomes available. Waiting for complete information before reporting is not an option — the 72-hour clock runs from discovery regardless of information completeness.",
    "burn": "The adversary does not pause exfiltration while you compile a complete incident report.",
    "roast": "Submit whatever information is available within 72 hours via DC3, then file follow-on reports as the investigation develops. The clock doesn't wait for a complete picture."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "What portal does DFARS 252.204-7012 require contractors to use for cyber incident reporting?",
    "opts": [
      "SPRS (Supplier Performance Risk System)",
      "The contractor's own internal ticketing system with DoD CC",
      "PIEE (Procurement Integrated Enterprise Environment)",
      "DC3 portal (dc3.mil)"
    ],
    "ans": 3,
    "compliment": "DC3. Not an email. Not a phone call. Not SPRS. DC3. Good.",
    "praise": "DC3 (dc3.mil) is the DoD's single reporting mechanism for contractor cyber incident reporting. The Incident Collection Format (ICF) on the DC3 portal requires a DoD-approved medium assurance PKI certificate for access. DC3 streamlines reporting and prevents duplicate submissions across different DoD offices.",
    "burn": "SPRS is for cyber incident reporting? SPRS is for performance data and assessment scores — not incident reports.",
    "roast": "SPRS is for performance data and assessment scores. DC3 is for cyber incident reports. Different systems, different purposes. Report to the right one."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under NIST SP 800-171 DoD Assessment Methodology, what score does a contractor receive if ALL 110 security requirements are fully implemented?",
    "opts": [
      "0 points (baseline)",
      "100 points",
      "110 points",
      "Score depends on weighted requirements"
    ],
    "ans": 2,
    "compliment": "110 MAXIMUM. You did not say 100. We noticed. It matters.",
    "praise": "110 points. The maximum possible score equals the total number of NIST SP 800-171 security requirements. For each unimplemented requirement, the associated point value is subtracted. Weighted requirements (those with greater security impact) subtract 5 points when not met; moderate impact requirements subtract 3; others subtract 1. Scores can go negative.",
    "burn": "100 points maximum? The baseline is 110 — one point per requirement, with weighted deductions for high-impact gaps.",
    "roast": "The DoD Assessment Methodology starts at 110 and deducts for unimplemented requirements, weighted by impact. Scores can go negative. 100 is not the ceiling."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under DFARS 252.204-7012, how must subcontractors report cyber incidents to DoD?",
    "opts": [
      "Through the prime contractor who reports to DoD",
      "Directly to DoD via DC3, providing only the incident report number to the prime",
      "Via secure email to the Contracting Officer within 72 hours",
      "Through DCMA who relays to DoD"
    ],
    "ans": 1,
    "compliment": "SUBCONTRACTOR REPORTING CHAIN CLEAR! Direct to DoD, incident number to prime — FAQ Q46 by the book!",
    "praise": "FAQ Q46 is clear: subcontractors report directly to DoD via DC3 and provide only the automatically assigned incident report number to the prime or next higher-tier sub. The prime does not act as an intermediary for the actual incident report. This ensures DoD receives direct, unfiltered incident information.",
    "burn": "Routing incident reports through the prime creates an information filter between DoD and the actual event.",
    "roast": "Subcontractors report directly to DoD via DC3 and provide only the incident report number to the prime. The prime is not an intermediary for the actual report."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under NIST SP 800-171, what is the difference between 'Basic Security Requirements' and 'Derived Security Requirements'?",
    "opts": [
      "Basic requirements are optional; Derived are mandatory",
      "Basic come from FIPS 200 (minimum requirements); Derived come from NIST 800-53 Moderate baseline",
      "Basic are policy controls; Derived are technical controls",
      "Basic apply to Level 1; Derived apply to Level 2"
    ],
    "ans": 1,
    "compliment": "BASIC FROM FIPS 200. DERIVED FROM 800-53. Both mandatory. You actually know the origin story.",
    "praise": "Per NIST SP 800-171 FAQ Q52: Basic Requirements come from FIPS 200 (minimum security requirements) and Derived Requirements come from the NIST SP 800-53 Moderate baseline. Both are mandatory — meeting the Basic does not satisfy the Derived. They work together to provide the complete protection framework.",
    "burn": "Basic requirements are optional? All requirements in 800-171 are mandatory. Basic and Derived both must be met.",
    "roast": "Basic and Derived Requirements are both mandatory — meeting one does not satisfy the other. Basic Requirements set the foundation; Derived Requirements implement the specifics."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "What is 'Controlled Technical Information' (CTI) under DFARS clause 252.204-7012?",
    "opts": [
      "Classified technical specifications for defense systems",
      "Any technical document marked with any distribution statement",
      "Technical information with military or space application subject to access controls, which meets Distribution Statement B-F criteria",
      "All technical data owned by DoD"
    ],
    "ans": 2,
    "compliment": "CTI DEFINED CORRECTLY. Statement A is not CTI. You read past the first line of the definition.",
    "praise": "CTI is technical information with military or space application that is subject to access, use, reproduction, or dissemination controls — and which would meet Distribution Statement B-F criteria if disseminated. It includes engineering data, drawings, specifications, technical reports, and computer software. It does not include publicly available information.",
    "burn": "Distribution Statement A is unlimited distribution. Publicly available. Not CTI by definition.",
    "roast": "CTI requires both military/space application AND controlled dissemination (Statements B-F). Statement A is unlimited distribution — publicly available, not CTI by definition."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "NIST SP 800-171 requirement 3.5.3 requires multifactor authentication. Which of the following does NOT qualify as a valid MFA factor?",
    "opts": [
      "Something you know (password)",
      "Where you are (controlled access facility)",
      "Something you have (OTP device, smart card)",
      "Something you are (biometric)"
    ],
    "ans": 1,
    "compliment": "LOCATION IS NOT AN MFA FACTOR. Everyone in the building simultaneously satisfies it. You caught that.",
    "praise": "FAQ Q81 explicitly states that location — even within a controlled access facility — is NOT a valid MFA factor. Valid factors are what you know, what you have, and what you are. Location is a shared environmental condition, not unique to the individual being authenticated. MFA requires at least two of the three valid factors.",
    "burn": "Everyone in the building satisfies the location factor simultaneously. It cannot distinguish individuals.",
    "roast": "Location fails as an MFA factor because everyone in the building satisfies it simultaneously — it can't distinguish individuals. Valid factors are know, have, and are."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under CMMC 2.0, what assessment level is required for Level 2 contractors NOT in prioritized acquisitions?",
    "opts": [
      "Annual government assessment by DCSA",
      "C3PAO third-party assessment",
      "Triennial self-assessment with senior official affirmation",
      "No assessment required — Level 2 is voluntary"
    ],
    "ans": 2,
    "compliment": "TWO TRACKS. YOU PICKED THE RIGHT ONE. Non-prioritized Level 2 self-assesses. Prioritized gets a C3PAO. Yes.",
    "praise": "Under CMMC 2.0, Level 2 contractors not in prioritized acquisitions conduct triennial self-assessments with senior official affirmation submitted to SPRS. Prioritized acquisitions require C3PAO third-party assessments. Level 3 requires government-led DCSA assessments. Understanding the tiered assessment model is fundamental.",
    "burn": "No assessment required for Level 2? All Level 2 contractors must at minimum self-assess and affirm to SPRS.",
    "roast": "Level 2 non-prioritized contractors conduct triennial self-assessments with senior official affirmation. Prioritized acquisitions require C3PAO assessment. Neither track means no assessment."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "What does NIST SP 800-171 requirement 3.12.4 require?",
    "opts": [
      "Annual penetration testing of all CUI systems",
      "A System Security Plan (SSP) describing the system boundary, environment, and how requirements are implemented",
      "Quarterly risk assessments submitted to the program office",
      "A Plan of Action and Milestones (POA&M) for all unmet requirements"
    ],
    "ans": 1,
    "compliment": "3.12.4. SSP. Four required elements. You named them without looking them up. Good.",
    "praise": "Requirement 3.12.4 requires a System Security Plan that describes the system boundary, system environments of operation, how security requirements are implemented, and relationships with or connections to other systems. The SSP is a living document — it must be periodically updated. It is not the same as a POA&M (3.12.2), though both may be combined into one document.",
    "burn": "3.12.4 is the SSP requirement. Quarterly submissions to the program office do not exist in this requirement.",
    "roast": "Four distinct requirements — SSP (3.12.4), POA&M (3.12.2), periodic risk assessment (3.11.1), and security control assessment (3.12.1). Conflating them is a gap in 800-171 structural literacy."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Which of the following accurately describes when 'For Official Use Only' (FOUO) information constitutes covered defense information under DFARS 252.204-7012?",
    "opts": [
      "All FOUO information is automatically covered defense information",
      "FOUO information is exempt from DFARS 252.204-7012",
      "FOUO is equivalent to CUI in all circumstances",
      "FOUO alone does not indicate covered defense information — additional dissemination controls must apply"
    ],
    "ans": 3,
    "compliment": "FOUO ≠ CUI AUTOMATICALLY. You read past the marking to the actual regulatory test. Nice.",
    "praise": "FAQ Q25 is explicit: FOUO alone does not indicate covered defense information. For FOUO information to require DFARS safeguarding it must also include applicable dissemination, release, and distribution statements consistent with law, regulation, or government-wide policies. Most FOUO information does not meet this threshold. DoDI 5200.48 has since updated FOUO marking guidance.",
    "burn": "All FOUO is automatically covered defense information? FAQ Q25 says exactly the opposite.",
    "roast": "FOUO alone does not indicate covered defense information — additional dissemination controls must also apply. Most FOUO information doesn't meet the threshold. FAQ Q25 is explicit."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under CMMC 2.0, what is required from senior officials when a contractor submits a self-assessment to SPRS?",
    "opts": [
      "The assessment must be co-signed by the Contracting Officer",
      "A senior official must affirm the accuracy of the self-assessment results",
      "Senior officials must obtain a C3PAO countersignature",
      "Senior official review is optional for self-assessments"
    ],
    "ans": 1,
    "compliment": "SENIOR OFFICIAL AFFIRMATION: IT HAS TEETH. You understand why a C-suite signature isn't ceremonial.",
    "praise": "CMMC 2.0 requires a senior official affirmation — a formal attestation by a company executive that the self-assessment results are accurate. This creates individual accountability for false SPRS submissions and significantly raises the legal risk of inflated self-assessments. The affirmation is what gives the self-assessment legal weight under the False Claims Act framework.",
    "burn": "Optional. The affirmation is specifically designed so that it is not optional.",
    "roast": "The Affirming Official personally attests to SPRS accuracy — creating individual FCA exposure for knowingly false submissions. A C-suite signature on a fabricated score is not ceremonial."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "What does 'FCI' stand for in the context of CMMC Level 1?",
    "opts": [
      "Federal Cybersecurity Infrastructure",
      "Federal Contract Information",
      "Federally Controlled Inventory",
      "Federal Classified Information"
    ],
    "ans": 1,
    "compliment": "FCI. FEDERAL CONTRACT INFORMATION. Not classified. Not CUI. Level 1. You know your acronyms.",
    "praise": "Federal Contract Information — information provided by or generated for the government under contract that is not intended for public release. CMMC Level 1 uses 17 basic safeguarding practices from FAR 52.204-21 to protect FCI. CUI (Controlled Unclassified Information) is protected at Level 2 and above.",
    "burn": "FCI is unclassified. Federal Contract Information. Not classified. Very different regulatory universe.",
    "roast": "FCI is unclassified — it just can't be publicly released. Classified information is a completely separate regulatory universe. FCI is Level 1. CUI is Level 2. Classification is something else entirely."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under CMMC 2.0, a contractor achieves CMMC Level 2 certification from a C3PAO. How long is the certification valid?",
    "opts": [
      "One year",
      "Three years",
      "Two years",
      "Five years"
    ],
    "ans": 1,
    "compliment": "THREE YEARS. C3PAO. VALID. You know the program architecture well enough to schedule around it.",
    "praise": "CMMC Level 2 C3PAO assessments are valid for three years. This aligns with the anticipated NIST SP 800-171 DoD Assessment cycle described in FAQ Q125. Annual affirmations may be required during the three-year period, but the primary assessment cycle is triennial.",
    "burn": "Annual C3PAO recertification would break the entire defense industrial base. Three years is the cycle.",
    "roast": "CMMC Level 2 C3PAO certifications are valid for three years, aligned with the 800-171 DoD Assessment methodology's anticipated cycle. Annual affirmations may be required in interim years."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "The security requirements in DFARS 252.204-7012 must be implemented WHEN?",
    "opts": [
      "At contract award regardless of CUI flow",
      "Only after DoD provides formal CUI markings",
      "Within 90 days of contract award",
      "When covered defense information is processed, stored, or transmitted on contractor systems in performance of the contract"
    ],
    "ans": 3,
    "vars": [
      {
        "q": "A defense contractor signs a DoD contract that includes DFARS 252.204-7012. The contract involves software development but CUI won't flow to the contractor's systems until Phase 2, six months away. When must 800-171 be implemented?",
        "opts": [
          "Immediately at contract award",
          "When covered defense information is actually processed, stored, or transmitted on contractor systems during contract performance",
          "Within 90 days of contract award",
          "When Phase 2 begins and CUI starts flowing"
        ],
        "ans": 1
      }
    ],
    "compliment": "CLAUSE ≠ OBLIGATION. CUI FLOW = OBLIGATION. You found the trigger in the FAQ. Most people don't.",
    "praise": "FAQ Q6 is precise: DFARS 252.204-7012 requirements must be implemented when covered defense information is processed, stored, or transmitted on contractor information systems in performance of the contract. If CUI never touches contractor systems, the requirements don't apply — even if the clause is in the contract. The data flow activates the obligation.",
    "burn": "Clause in the contract but no CUI flowing. The security requirements are not yet triggered.",
    "roast": "The clause can be in the contract while the requirements remain dormant — they activate when CUI actually flows to contractor systems in contract performance. Data flow is the trigger, not contract award."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During a CMMC Level 2 assessment, the OSC has a compensating control for a practice because their legacy system cannot be patched. What is the CORRECT assessor action?",
    "opts": [
      "Auto-mark 'Not Met' — compensating controls are never accepted",
      "Document the control, evaluate its effectiveness, determine if practice intent is met",
      "Accept it without evaluation — the OSC said it works",
      "Escalate immediately to DIBCAC before evaluating"
    ],
    "ans": 1,
    "compliment": "COMPENSATING CONTROL CONNOISSEUR! The assessment gods are weeping tears of absolute joy!",
    "praise": "Document and evaluate! Compensating controls must be assessed against whether they satisfy the intent and objectives of the practice. You didn't rubber-stamp or auto-fail. You assessed. That is why C3PAOs exist. That is the job description. Frame this answer and hang it in your office.",
    "burn": "You auto-failed a compensating control without looking at it. That's not assessing. That's stamping.",
    "roast": "Compensating controls exist because real-world systems have real constraints. The assessor evaluates equivalence and checks for formal CIO adjudication — not auto-fails without investigation."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "The three primary assessment methods defined in NIST SP 800-171A are:",
    "opts": [
      "Interview, Examine, Test",
      "Analyze, Verify, Confirm",
      "Review, Test, Observe",
      "Document Review, Penetration Test, Audit"
    ],
    "ans": 0,
    "compliment": "ASSESSMENT METHODOLOGY MASTER! Interview, Examine, Test — the sacred trinity recited perfectly!",
    "praise": "Interview, Examine, Test! These three assessment methods from NIST SP 800-171A form the methodological foundation of every CMMC assessment. You interview personnel, you examine documentation and configurations, you test controls. You know your methodology cold.",
    "burn": "Review, Test, Observe is not the NIST 800-171A assessment method trio. It's Interview, Examine, Test.",
    "roast": "The three assessment methods in 800-171A are Interview, Examine, and Test. If you're assessing under CMMC and don't know the three assessment methods, that's a meaningful gap."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What does it mean for a CMMC practice to be assessed as 'Met'?",
    "opts": [
      "The OSC has fully implemented the practice and objective evidence confirms it",
      "A majority of the practice's requirements are implemented",
      "The OSC has documented the practice in their SSP",
      "The OSC has a plan to implement the practice within 90 days"
    ],
    "ans": 0,
    "compliment": "'MET' DEFINITION MASTER! Full implementation plus objective evidence — the complete definition!",
    "praise": "Met means fully implemented AND confirmed by objective evidence. SSP documentation alone is not Met. A plan is not Met. Partial implementation is Not Met. The practice is either fully in place with verifiable evidence, or it isn't. You know exactly where the bar is.",
    "burn": "A documented plan means Met? A plan to be compliant is not compliance. Plans are POA&Ms.",
    "roast": "The SSP is a description of claimed implementation. The assessment determines whether those claims are accurate. Writing 'we do MFA' in an SSP and implementing MFA are entirely different things."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What is the purpose of the System Security Plan (SSP) in a CMMC assessment?",
    "opts": [
      "It substitutes for an interview if the system owner is unavailable",
      "It is a legal contract between the OSC and the C3PAO",
      "It provides the authoritative description of the system boundary, controls, and implementation details the assessor uses as a starting point",
      "It replaces the need for evidence collection during the assessment"
    ],
    "ans": 2,
    "compliment": "SSP SCHOLAR! You know exactly what the System Security Plan is for and what it is not!",
    "praise": "The SSP describes the system boundary, implemented controls, and the OSC's implementation approach — it's the assessor's starting reference point for understanding what the OSC claims to have in place. Then the assessment verifies those claims through interview, examination, and testing. The SSP is a claim document, not a verified evidence package.",
    "burn": "The SSP says what the OSC claims. The assessment determines if those claims are true.",
    "roast": "The SSP describes what the OSC claims. The assessment determines whether those claims are accurate. A polished SSP that doesn't match reality is a roadmap to your biggest findings."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What type of evidence is MOST reliable when assessing whether an access control practice is implemented?",
    "opts": [
      "The OSC's policy document stating the practice is required",
      "A screenshot of the system configuration showing the control in place",
      "The SSP's description of the implementation",
      "Verbal confirmation from the system administrator"
    ],
    "ans": 1,
    "compliment": "EVIDENCE HIERARCHY EXPERT! Configuration screenshots over policy documents — you know the hierarchy!",
    "praise": "System configuration screenshots are direct technical evidence of implementation. Policy documents say what should happen. Configurations show what actually happens. Verbal confirmation is interview evidence — useful but unverified. The SSP is a claim document. Direct examination of system configurations is your strongest evidence for implemented technical controls.",
    "burn": "Policy documents confirm implementation? Policies describe what should happen. Configs show what does happen.",
    "roast": "A policy says 'we require MFA.' The system configuration shows whether MFA is actually enforced. These are completely different things and only one of them is evidence of implementation."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "After completing an assessment, an OSC asks you informally whether they 'passed' before the official report is finalized. What do you say?",
    "opts": [
      "Give them the result if they agree not to share it publicly",
      "Provide a general sense of the outcome to manage expectations",
      "Give them a preliminary verbal result — they deserve to know",
      "Explain that official results are communicated through the formal report process only — no preliminary results"
    ],
    "ans": 3,
    "compliment": "PROCESS PROTECTOR! You held the line on formal reporting — that's professional discipline!",
    "praise": "Official results are communicated through the formal report process only. Preliminary informal results — even well-intentioned ones — can create legal and professional complications if the formal finding differs. You maintain the integrity of the process. The OSC gets their answer through official channels.",
    "burn": "Informal verbal results before the report? What happens when the formal finding differs from your verbal preview?",
    "roast": "Informal verbal results before the formal report create serious problems — the OSC acts on them, tells the CO, plans bids, then the formal report may differ. No informal results. Report first."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During an opening conference, the OSC's CEO states the company is 'fully compliant with everything.' What is the FIRST thing a professional assessor does with this information?",
    "opts": [
      "Report the claim to the Contracting Officer as a red flag",
      "Ask the CEO to sign a compliance affidavit immediately",
      "Accept it and reduce the assessment scope",
      "Document the statement and proceed with objective evidence collection"
    ],
    "ans": 3,
    "compliment": "CEO SAYS COMPLIANT. YOU SAID 'NOTED.' Then you opened your evidence checklist. Perfect.",
    "praise": "Document the CEO's statement and proceed with objective evidence collection. Oral assertions — including from the most senior person in the room — are not assessment evidence. The assessor's job is to validate claims through documentation, interviews at multiple levels, and technical testing. The CEO's confidence is noted. The evidence determines the result.",
    "burn": "Accept it and reduce scope? The CEO says they're compliant. The assessor's job is to find out if that's true.",
    "roast": "Document the CEO's statement and proceed with objective evidence collection. Oral assertions from executives are not assessment evidence — the evidence determines the finding."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "An OSC presents a well-formatted SSP with detailed descriptions of how each requirement is met. What should the assessor do with this document?",
    "opts": [
      "Submit it to DCSA for independent verification",
      "Use it as a roadmap for focused evidence collection and validation",
      "Accept it as evidence of compliance for all documented requirements",
      "Consider it self-serving and discount it entirely"
    ],
    "ans": 1,
    "compliment": "SSP = ROADMAP. NOT FINISH LINE. You understand what it's for and what it isn't. That's the whole game.",
    "praise": "Use the SSP as a roadmap for focused evidence collection. The SSP tells you what the OSC claims — your job is to validate those claims through interviews, artifact review, and technical observation. A well-written SSP that accurately reflects reality is a gift to an assessor. A polished SSP that doesn't match reality is the setup for a major finding.",
    "burn": "The SSP describes claimed implementation. Evidence determines if the claims are accurate.",
    "roast": "Use the SSP as a roadmap for evidence collection, not as the evidence itself. A beautifully formatted SSP that doesn't match operational reality is the setup for a major finding."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During an interview, a system administrator says 'we do that' regarding a security practice but cannot describe HOW it is done. What does this indicate?",
    "opts": [
      "The practice is implemented — the admin is just modest",
      "This is normal — not all staff know technical details",
      "The admin needs remediation training before the assessment continues",
      "The practice may not be implemented or may not be understood at the operational level"
    ],
    "ans": 3,
    "compliment": "'WE DO THAT.' You heard what that actually means and asked the follow-up. Most assessors nod and move on.",
    "praise": "When a system administrator cannot describe HOW a practice is implemented, it's a signal that either the practice isn't actually implemented, the admin isn't the right person to ask, or there's an awareness gap. Follow up by requesting documentation, asking to observe the control, or interviewing the person responsible for implementation. 'We do that' is not evidence.",
    "burn": "'We do that' with no explanation of how is a compliance talking point. Not a control.",
    "roast": "When an admin can't explain how a control is implemented, probe further — request documentation, ask to observe, or find the person who actually owns it. 'We do that' is a starting point, not evidence."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What is the PRIMARY purpose of a Plan of Action and Milestones (POA&M) in the CMMC assessment context?",
    "opts": [
      "To request an assessment extension from the C3PAO",
      "To document all practices the OSC plans to implement after certification",
      "To identify deficiencies and provide a credible remediation plan with timelines",
      "To inform DoD of every security gap found during self-assessment"
    ],
    "ans": 2,
    "compliment": "POA&M: HONEST GAPS. CREDIBLE PLAN. REAL TIMELINE. Not a holding pattern. You know the difference.",
    "praise": "A POA&M (NIST SP 800-171 requirement 3.12.2) identifies security requirement deficiencies and provides a documented plan with timelines to correct them. It's a living document — not a one-time filing. Assessors evaluate whether the POA&M reflects honest gaps and credible remediation plans, not whether it makes the OSC look good.",
    "burn": "A POA&M is a request for assessment extension? It's a remediation planning document — not an extension request.",
    "roast": "A POA&M lists gaps, provides credible remediation plans with timelines, and demonstrates honest awareness. 'Implement MFA — timeline: unspecified' is not a compliant POA&M."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During a CMMC assessment, the OSC's CISO becomes hostile and refuses to provide access to a requested system. What is the correct assessor response?",
    "opts": [
      "Continue the assessment on other systems and ignore the refused access",
      "Immediately terminate the assessment and issue a Not Met for all practices",
      "Document the refusal, explain the impact on the assessment, and escalate through proper channels",
      "Accept whatever the CISO provides and adjust the finding accordingly"
    ],
    "ans": 2,
    "compliment": "HOSTILE CISO. DOCUMENTED. ESCALATED. Assessment continued. You don't fold when someone raises their voice.",
    "praise": "Document the refusal clearly in assessment workpapers, explain to the CISO and appropriate OSC leadership the impact the refusal has on the assessment (findings may be made based on available evidence, with the refusal itself noted), and escalate through proper channels per the assessment methodology. Hostile behavior doesn't change the assessor's methodology — it becomes part of the documented record.",
    "burn": "One hostile CISO. Assessment terminated. Professional response was available. You chose drama.",
    "roast": "Document the refusal, explain the impact on the assessment, and escalate through proper channels. One hostile CISO doesn't end an assessment — it becomes part of the documented record."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "Which of the following is the BEST definition of 'objective evidence' in CMMC assessment?",
    "opts": [
      "Any document the OSC provides during the assessment",
      "Documented information, records, or observations that can be verified and validated",
      "Security scan results from the past 12 months only",
      "Written attestation from the OSC's senior leadership"
    ],
    "ans": 1,
    "compliment": "OBJECTIVE EVIDENCE: VERIFIABLE. VALIDATED. Not 'whatever arrived in the document dump this morning.'",
    "praise": "Objective evidence is documented information, records, or observations that can be verified and validated. It's distinguished from subjective claims or assertions. Evidence sources include: documents (policies, procedures), records (logs, audit trails, training records), observations (system configuration review, process walkthroughs), and interviews (corroborated across multiple sources). The key attribute is verifiability.",
    "burn": "Any document the OSC provides? OSCs can provide documents that say anything. Objective evidence must be verifiable.",
    "roast": "Objective evidence is documented information or observations that can be verified and validated — not whatever arrived in the document package. The 'objective' in objective evidence means verifiable independently."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What is the CMMC Assessment Process (CAP) document's primary function for assessors?",
    "opts": [
      "It defines the 110 NIST SP 800-171 practices",
      "It provides the standardized methodology for conducting CMMC Level 2 assessments including phases and activities",
      "It specifies the scoring weights for each practice",
      "It lists all approved C3PAOs"
    ],
    "ans": 1,
    "compliment": "THE CAP: METHODOLOGY. Not practices. Not scoring. Methodology. You know which document does what.",
    "praise": "The CAP provides the standardized methodology for CMMC Level 2 assessments — defining the phases (Plan and Prepare, Conduct, Report), activities within each phase, assessor roles and responsibilities, and documentation requirements. It's the operational guide for C3PAOs conducting assessments. NIST 800-171 defines the practices; the CAP defines how to assess them.",
    "burn": "The CAP lists all approved C3PAOs? That's the CYBER-AB marketplace. The CAP is a methodology document.",
    "roast": "The CAP defines assessment phases and activities. NIST SP 800-171 defines the practices. The DoD Assessment Methodology defines scoring. Three separate documents with three separate functions."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "An OSC has 200 users. An assessor wants to verify that all users completed security awareness training (3.2.1). What is a reasonable approach?",
    "opts": [
      "Accept a written attestation from the training coordinator",
      "Review only the records of users who work in the CUI environment",
      "Interview all 200 users",
      "Review training completion records from the LMS and sample-test 10-15 users' records against the system"
    ],
    "ans": 3,
    "compliment": "LMS RECORDS + SAMPLE VALIDATION. Not 200 interviews. Not blind faith. Efficient and defensible.",
    "praise": "Review training records from the LMS for completeness (all 200 users) and validate a sample against the source system to verify the records are accurate and not fabricated. Interview a sample of users to confirm they received and understood the training. This combines record review with corroboration — the backbone of efficient assessment evidence collection.",
    "burn": "Interview all 200 users? That's technically thorough and practically impossible in any reasonable assessment timeline.",
    "roast": "Review LMS records for completeness, validate a sample against the source system, and corroborate with targeted interviews. Sampling exists precisely for populations of this size."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During a CMMC assessment, what does it mean to 'validate' vs 'verify' evidence?",
    "opts": [
      "Verify means the evidence exists; validate means it is accurate and sufficient to support the finding",
      "Verify is for technical evidence; validate is for policy documents",
      "They mean the same thing in assessment terminology",
      "Validate is the assessor's function; verify is the OSC's function"
    ],
    "ans": 0,
    "compliment": "EVIDENCE METHODOLOGY PRECISION! Verify existence, validate accuracy and sufficiency — assessment rigor defined!",
    "praise": "Verification confirms the evidence exists. Validation confirms it is accurate, authentic, and sufficient to support the scoring determination. Both are essential. A screenshot showing MFA is enabled (verified) but taken from a test environment that doesn't represent production (not validated) is not reliable assessment evidence.",
    "burn": "They mean the same thing. They do not mean the same thing.",
    "roast": "Verify confirms a thing exists. Validate confirms it's accurate and sufficient to support the finding. Both steps are required — they're not synonyms."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During an interview, an OSC employee describes a security process that differs significantly from the SSP documentation. What should the assessor do?",
    "opts": [
      "Document the discrepancy and investigate further through additional interviews and technical evidence",
      "Believe the employee — they implement the practice daily",
      "Report the discrepancy to the Contracting Officer immediately",
      "Believe the SSP — it's the official documentation"
    ],
    "ans": 0,
    "compliment": "SSP SAYS ONE THING. EMPLOYEE SAYS ANOTHER. You investigated instead of picking a favorite.",
    "praise": "Document the discrepancy and investigate. SSP documentation and operational reality don't always match — and both directions of mismatch are possible. The SSP might describe aspirational state. Or the employee might describe a workaround. Or the SSP might not have been updated to reflect a process change. Corroborate through additional interviews, technical observations, and system logs before drawing conclusions.",
    "burn": "The SSP describes intentions. The employee describes operations. You need to know which matches reality.",
    "roast": "SSP documents what should happen. Employee interviews describe what does happen. When they conflict, investigate through additional interviews, observations, and system evidence — don't pick a side."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What happens to a CMMC certification if the OSC undergoes a material change to their system boundary after certification?",
    "opts": [
      "The OSC notifies DoD and has 90 days to certify the new systems",
      "The certification remains valid for the original three-year period regardless",
      "The OSC should assess the change's impact on their CMMC compliance and may need to update their SSP, POA&M, and potentially undergo reassessment",
      "The OSC must immediately recertify from scratch"
    ],
    "ans": 2,
    "compliment": "POST-CERTIFICATION CHANGE MANAGEMENT CORRECT! Impact assessment, SSP update, potential reassessment — sound compliance governance!",
    "praise": "Material system changes after certification require the OSC to assess the impact on their CMMC compliance posture. The SSP must be updated to reflect the new boundary. If the change introduces new systems or significantly modifies the assessed environment, reassessment may be required. CMMC compliance is ongoing — not a one-time achievement.",
    "burn": "30 unassessed systems now in the CUI environment. The certification that predates them is silent on all 30.",
    "roast": "A material system change after certification means the cert no longer covers the full current environment. Evaluate the change, update the SSP, address gaps, and determine whether reassessment is required."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What is the purpose of the 'artifacts' that an OSC provides during an assessment?",
    "opts": [
      "To satisfy a documentation checklist requirement only",
      "To impress the assessor with documentation volume",
      "To provide objective evidence that security practices are implemented and operating effectively",
      "To demonstrate the OSC's security budget allocation"
    ],
    "ans": 2,
    "compliment": "ARTIFACT PURPOSE CLEAR! Objective evidence of implementation and operational effectiveness — correct!",
    "praise": "Artifacts (documents, records, screenshots, logs, configurations) provide objective evidence that security practices are implemented and operating. They're the evidentiary basis for assessment findings. Volume is irrelevant — relevance, accuracy, and completeness are what matter. A focused set of precise artifacts beats a warehouse of tangentially related documents.",
    "burn": "Documentation volume impresses assessors? Dumping 500 irrelevant documents is not evidence — it's distraction.",
    "roast": "500 documents dumped the morning of kickoff is either organizational chaos or strategic friction. Prioritize the SSP and scope documentation, work through the rest systematically. Volume is not evidence."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "An OSC's password policy requires 12-character minimum passwords. DoD guidance specifies a minimum of 15 characters when MFA is not implemented. How should the assessor handle this gap?",
    "opts": [
      "Accept it — 12 characters is close enough to 15",
      "Not Met — the organization's policy doesn't meet DoD guidance when MFA is not implemented",
      "Request a DoD CIO variance approval before scoring",
      "Met — password policies are organization-defined under 800-171"
    ],
    "ans": 1,
    "compliment": "POLICY PARAMETER PRECISION! FAQ Q53.1 sets 15-character minimum without MFA — 12 doesn't meet it!",
    "praise": "Not Met for the password policy parameter. DFARS FAQ Q53.1 provides specific guidance: when MFA is not implemented, the minimum password complexity includes a minimum of 15 characters with complexity requirements. The OSC's 12-character policy falls short of this specific DoD guidance. This is a scoring finding for the password management practice.",
    "burn": "Close enough? Assessment scoring doesn't have a 'close enough' option. 12 is not 15.",
    "roast": "DoD guidance specifies a 15-character minimum when MFA is not implemented. The OSC's 12-character policy doesn't meet it. 12 is not 15."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "TRUE OR FALSE: An OSC can achieve CMMC Level 3 certification through self-attestation.",
    "opts": [
      "TRUE — with annual affirmation, self-attestation applies to all levels",
      "FALSE — self-attestation is not permitted for any CMMC level",
      "TRUE — all CMMC levels allow self-attestation as an option",
      "FALSE — Level 3 requires government-led assessment, not self-attestation"
    ],
    "ans": 3,
    "compliment": "LEVEL 3 GOVERNANCE GURU! Self-attestation stops at Level 2 — you knew exactly where the line is!",
    "praise": "False! Level 3 requires government-led assessment by DCSA teams. There is no self-attestation path for Level 3. The sensitivity of Level 3 programs demands direct government oversight. You understand the governance structure across all three levels.",
    "burn": "Self-attestation for Level 3? That's a government-assessed level. DCSA comes to you for Level 3.",
    "roast": "Level 3 requires government-led assessment by DCSA — the most sensitive DoD programs require government oversight, not self-attestation. Self-attestation at Level 3 would make the certification meaningless."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "Which of the following is a VALID reason for an OSC to score themselves below their actual implementation level in SPRS?",
    "opts": [
      "They haven't finished their SSP yet",
      "Their IT team hasn't verified the configuration files",
      "There is no valid reason — SPRS scores must accurately reflect actual implementation",
      "They want to appear humble to the Contracting Officer"
    ],
    "ans": 2,
    "compliment": "SPRS ACCURACY ENFORCER! Intentionally under-reporting is as problematic as over-reporting!",
    "praise": "There is no valid reason to intentionally score below actual implementation. SPRS scores must accurately reflect the actual security posture — over-reporting creates False Claims Act exposure; under-reporting creates false impressions about the contractor's capabilities and compliance status. Accuracy is the requirement in both directions.",
    "burn": "Humility is not a SPRS scoring criterion. Accuracy is the criterion. Only accuracy.",
    "roast": "Under-reporting in SPRS isn't humility — it's inaccuracy. An OSC that under-represents their score is still submitting a false record. SPRS scores must be accurate in both directions."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "CUI stands for Controlled Unclassified Information. What is the key distinction between CUI and CLASSIFIED information?",
    "opts": [
      "CUI and classified are interchangeable terms for sensitive government data",
      "CUI is less sensitive than classified and has no legal protection",
      "CUI is unclassified but still controlled — it requires protection but through regulatory frameworks, not national security classification",
      "CUI only applies to DoD contractors, while classified applies to government agencies"
    ],
    "ans": 2,
    "compliment": "CUI VS. CLASSIFIED CLARITY! You defined the distinction with precision — that's foundational mastery!",
    "praise": "CUI is unclassified information requiring protection under law, regulation, or government-wide policy — but it is NOT classified national security information. It sits between 'publicly releasable' and 'classified.' CUI protection is governed by regulatory frameworks (like CMMC) rather than national security classification authorities. The distinction matters enormously in practice.",
    "burn": "CUI has no legal protection? 32 CFR Part 2002 and the entire CUI program would like a word with you.",
    "roast": "CUI is protected under law and regulation — EO 13556, 32 CFR Part 2002, DFARS clauses, and CMMC itself. The entire program exists because protecting CUI has legal force and national security significance."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 2,
    "q": "What is the primary difference between an assessment 'finding' and an 'observation'?",
    "opts": [
      "A finding is a documented deficiency against a specific requirement; an observation is a noted concern that doesn't rise to a formal deficiency",
      "There is no difference — the terms are interchangeable in CMMC assessments",
      "Findings are scored Not Met; observations are scored Partially Met",
      "Findings require remediation; observations are optional to address"
    ],
    "ans": 0,
    "compliment": "FINDING VS OBSERVATION: DEFINED. You know the distinction that keeps assessment reports defensible.",
    "praise": "A finding documents a specific deficiency against a named practice — it drives the Met/Not Met scoring decision. An observation notes something of concern that doesn't constitute a formal deficiency but warrants attention. Both belong in workpapers; only findings affect scores.",
    "burn": "No difference — they mean the same thing? Assessment reports would like a word.",
    "roast": "Treating findings and observations as interchangeable produces sloppy reports and confused remediation plans. Findings are scored. Observations inform. Know which is which before you close out."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 2,
    "q": "During an assessment interview, the system owner says 'I think we do that.' What is the correct assessor response?",
    "opts": [
      "Accept it — the system owner has authority",
      "Ask the system owner to show you documentation or demonstrate the control",
      "Mark it Met with low confidence",
      "Escalate to the CISO for confirmation"
    ],
    "ans": 1,
    "compliment": "'I THINK WE DO THAT' → SHOW ME. You know oral confidence is not evidence.",
    "praise": "'I think we do that' is a prompt to investigate, not a finding. Ask for documentation, logs, a system screenshot, or a live demonstration. The system owner's belief about implementation is a starting point — not an endpoint.",
    "burn": "Accept it because they have authority? Authority doesn't substitute for evidence.",
    "roast": "System owners sincerely believe many things about their environments that turn out not to be true. Verify everything. Belief is not implementation."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "An OSC's access control policy requires MFA for all privileged accounts. During testing you find MFA is enforced on 18 of 20 privileged accounts. Two service accounts are exempted 'for operational reasons.' How do you score practice 3.5.3?",
    "opts": [
      "Partially Met — document the two exceptions",
      "Met with observation — note the service account exceptions",
      "Met — 90% compliance is strong",
      "Not Met — the requirement applies to all privileged accounts without exception unless a formal variance has been adjudicated"
    ],
    "ans": 3,
    "compliment": "ALL MEANS ALL. Two undocumented exceptions to MFA are a Not Met — you didn't round up.",
    "praise": "Practice 3.5.3 requires MFA for all privileged accounts. Two service accounts operating without MFA are a gap — unless a formal CIO variance has been adjudicated. 'Operational reasons' stated informally to an assessor is not a variance. Not Met.",
    "burn": "90% is strong — round it up to Met? CMMC doesn't have a curve. 90% is Not Met.",
    "roast": "'For operational reasons' is the most common justification for security exceptions. It is not a CMMC variance process. Two privileged accounts without MFA are a Not Met on 3.5.3 regardless of the operational rationale."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What does 'risk-based sampling' mean in the context of a CMMC assessment?",
    "opts": [
      "Assessing only the systems with the most recent audit findings",
      "Sampling only systems that the OSC designates as high-risk",
      "Prioritizing assessment resources on systems and controls with higher potential impact or known weaknesses rather than uniform coverage",
      "Randomly selecting a fixed percentage of all systems"
    ],
    "ans": 2,
    "compliment": "RISK-BASED SAMPLING UNDERSTOOD. Prioritize by impact — not by percentage or OSC designation.",
    "praise": "Risk-based sampling directs assessment effort toward higher-risk systems, controls with known weaknesses, or areas with gaps in documentation. It's not random and it's not determined by the OSC — it's the assessor's professional judgment about where gaps are most likely to exist and matter most.",
    "burn": "A fixed percentage of all systems? That's statistical sampling. Risk-based means something different.",
    "roast": "Uniform percentage sampling is efficient but not risk-based. Risk-based means your sample prioritizes the systems where a gap would matter most — CUI endpoints over printers, privileged accounts over standard user accounts."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "An assessor discovers that the OSC's incident response plan has not been tested in two years. Practice 3.6.2 requires testing incident response capabilities. How should this be scored?",
    "opts": [
      "Not Met — the requirement includes testing, not just documenting, incident response capabilities",
      "Met — having a plan satisfies the requirement",
      "Partially Met — the plan exists but testing is overdue",
      "Depends on whether an actual incident occurred in that period"
    ],
    "ans": 0,
    "compliment": "PLAN ≠ TESTED CAPABILITY. 3.6.2 requires both — you knew the difference.",
    "praise": "Practice 3.6.2 requires organizations to test their incident response capabilities — a plan alone is insufficient. Two years without a test is a Not Met finding. Whether an actual incident occurred is irrelevant — the practice requires proactive testing.",
    "burn": "Having a plan satisfies 3.6.2? The practice explicitly requires testing, not just planning.",
    "roast": "An untested incident response plan is optimistic fiction. Practice 3.6.2 requires testing — tabletop exercises, simulations, or functional drills. Two years without a test is a Not Met regardless of how good the plan looks on paper."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 2,
    "q": "What is the purpose of the CMMC 'Close-Out Briefing' at the end of an assessment?",
    "opts": [
      "To allow the OSC to dispute all findings before they are recorded",
      "To provide the OSC with a preliminary overview of assessment findings before the formal report",
      "To issue the official certification decision",
      "To obtain OSC sign-off that all findings are accepted"
    ],
    "ans": 1,
    "compliment": "CLOSE-OUT BRIEFING PURPOSE CLEAR. Preliminary findings — not final decisions, not sign-offs.",
    "praise": "The close-out briefing provides the OSC with a preliminary overview of findings before the formal report is issued. It allows the OSC to ask clarifying questions, provide additional evidence that may affect findings, and prepare for remediation. It is not the certification decision and it does not require OSC agreement.",
    "burn": "Issue the certification decision? The formal report comes after the briefing, not during it.",
    "roast": "Close-out briefings inform; they don't certify or settle disputes. Findings presented at close-out are preliminary. The formal report is the authoritative document. OSC disagreement with findings at close-out is noted — not grounds for automatic revision."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "An assessor finds that an OSC uses a third-party ticketing system to track security incidents. The system is not in the SSP and is hosted in a cloud environment with unknown compliance status. What is the immediate concern?",
    "opts": [
      "The ticketing system may contain CUI or CUI-related security data and its compliance status must be determined",
      "None — ticketing systems are administrative tools",
      "Accept it as Met for 3.6.1 because incident tracking exists",
      "It is only a concern if the ticketing system is the primary ITSM platform"
    ],
    "ans": 0,
    "compliment": "INCIDENT TICKETING SYSTEM SCRUTINIZED. Security data in unknown cloud = compliance question.",
    "praise": "An incident ticketing system may contain sensitive security information about CUI environment vulnerabilities, incidents, and investigation details. Its hosting in an unassessed cloud environment with unknown compliance status is a scoping and compliance concern. Investigate whether it stores CUI-related data and whether its compliance posture is appropriate.",
    "burn": "Ticketing systems are administrative tools outside scope? An incident ticket system describing active threats to CUI systems is not administrative trivia.",
    "roast": "Security incident tickets describe vulnerabilities, attack patterns, and system weaknesses in the CUI environment. That data warrants protection. An unknown cloud system hosting it is a scoping and compliance gap worth investigating."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What does NIST SP 800-171 practice 3.12.1 require?",
    "opts": [
      "Develop and implement a Plan of Action and Milestones",
      "Periodically assess the security controls in organizational systems to determine if they are effective",
      "Develop and maintain a System Security Plan",
      "Conduct risk assessments of organizational systems"
    ],
    "ans": 1,
    "compliment": "3.12.1 DEFINED. Periodic assessment of control effectiveness — distinct from the SSP and POA&M.",
    "praise": "Practice 3.12.1 requires periodic assessment of security controls to determine their effectiveness. This is distinct from 3.12.4 (SSP), 3.12.2 (POA&M), and 3.11.1 (risk assessment). The assessment activity under 3.12.1 feeds into the SSP and POA&M but is its own requirement.",
    "burn": "That's 3.12.4. Practice 3.12.1 is about assessing control effectiveness, not documenting the system.",
    "roast": "The Security Assessment family has four distinct practices. Conflating them is one of the most common gaps in assessor knowledge of the 800-171 structure."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "An assessment team member notices what appears to be an active CUI data breach during the assessment — live exfiltration visible in network monitoring logs. What is the correct immediate action?",
    "opts": [
      "Immediately notify the OSC and pause the assessment so the OSC can initiate incident response",
      "Continue the assessment but flag it in the final report",
      "Contact DCSA directly on behalf of the OSC",
      "Complete the assessment first — documenting the finding is the priority"
    ],
    "ans": 0,
    "compliment": "ACTIVE BREACH: NOTIFY AND PAUSE. Completing the assessment is not the priority when CUI is actively leaving the building.",
    "praise": "An active breach requires immediate notification to the OSC so they can initiate incident response. The assessment pauses. The assessor's role is not to manage the response — it is to notify the OSC and step aside for their incident response team. DFARS 252.204-7012 reporting obligations are the OSC's, triggered by this discovery.",
    "burn": "Complete the assessment first? CUI is actively exfiltrating and you want to finish the interview schedule.",
    "roast": "An active exfiltration event is not a finding to document in a report — it is an emergency requiring immediate OSC notification. Pause the assessment. Notify the right people. The documentation comes later."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 2,
    "q": "What is the key difference between the System Security Plan (SSP) and the Plan of Action and Milestones (POA&M)?",
    "opts": [
      "The SSP covers technical controls; the POA&M covers policy controls",
      "The SSP describes how security requirements are implemented; the POA&M documents gaps and the plan to remediate them",
      "The SSP is submitted to the government; the POA&M is internal only",
      "The SSP is for large organizations; the POA&M is for small ones"
    ],
    "ans": 1,
    "compliment": "SSP VS POA&M DISTINGUISHED. Describes implementation vs documents gaps — clean separation.",
    "praise": "The SSP (3.12.4) describes the system boundary, environment, and how each security requirement is implemented. The POA&M (3.12.2) documents the gaps — practices not yet fully implemented, with planned remediation timelines. They work together: the SSP says what is in place, the POA&M says what isn't and when it will be.",
    "burn": "SSP for large, POA&M for small? Both are required for every CMMC Level 2 organization regardless of size.",
    "roast": "Both documents are required. The SSP describes your current state. The POA&M documents your gap state and your remediation plan. Neither substitutes for the other."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During testing of practice 3.1.6 (use of non-privileged accounts for non-privileged tasks), you find that the IT administrator's privileged account is used for both privileged tasks AND daily email and web browsing. How is this scored?",
    "opts": [
      "Observation only — common practice in small organizations",
      "Not Met — the practice requires using non-privileged accounts for non-privileged activities to limit the attack surface of privileged credentials",
      "Met — IT admins need flexibility to do their jobs",
      "Partially Met — email is technically not a security-sensitive activity"
    ],
    "ans": 1,
    "compliment": "PRIVILEGED ACCOUNT HYGIENE ASSESSED CORRECTLY. Admin email = attack surface. Not Met.",
    "praise": "Practice 3.1.6 requires organizations to use non-privileged accounts for non-privileged activities. An admin using their privileged account for email and web browsing dramatically increases the attack surface — phishing email opened in a privileged session can compromise admin credentials directly. This is Not Met regardless of organizational size.",
    "burn": "IT admins need flexibility? The flexibility to do email in a privileged account is the flexibility to hand attackers admin credentials.",
    "roast": "Privileged accounts doing daily email and web browsing are one phishing click away from a full compromise. Practice 3.1.6 exists specifically to prevent this. Not Met."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "What does 'tailored assessment' mean for Specialized Assets under CMMC scoping?",
    "opts": [
      "Specialized Assets only require Level 1 practices",
      "Specialized Assets are exempt from all CMMC practices",
      "Specialized Assets require applying CMMC practices in a way appropriate to their technical characteristics, which may mean some practices apply differently or have alternative approaches",
      "Specialized Assets are assessed using a different scoring scale"
    ],
    "ans": 2,
    "compliment": "TAILORED ASSESSMENT FOR SPECIALIZED ASSETS UNDERSTOOD. In scope, different approach — not exempt.",
    "praise": "Specialized Assets (OT/ICS, IoT, medical devices, GFE) are in scope for the CMMC assessment — but their technical characteristics may require adapted approaches to specific practices. A production PLC may not support session lock the same way a workstation does. The tailored assessment documents how practices apply to the specific asset characteristics.",
    "burn": "Specialized Assets are exempt from CMMC practices? They're in scope — just assessed with adapted approaches.",
    "roast": "'Specialized' means the assessment approach is tailored to the asset type — not that the asset is exempt. OT systems in the CUI environment are in scope. The assessment methodology adapts to how practices apply to their specific technical characteristics."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 2,
    "q": "An assessor is reviewing a policy document for practice 3.2.1 (security awareness training). The policy is dated three years ago and has not been reviewed since. What is the relevance?",
    "opts": [
      "None — policy age doesn't affect the Met/Not Met determination",
      "The stale policy date is a signal to investigate whether the training content is current and whether the OSC's periodic review process is functioning",
      "Mark it Not Met automatically because the policy is outdated",
      "Accept it — policies don't need to be updated if the requirements haven't changed"
    ],
    "ans": 1,
    "compliment": "STALE POLICY = SIGNAL TO INVESTIGATE. Not an auto-fail, but definitely a follow-up.",
    "praise": "A three-year-old unreviewed policy is a signal — not an automatic Not Met. Investigate whether the training content reflects current threats and requirements, whether employees are actually completing training against this policy, and whether the OSC has a documented review cycle they're not following. The policy age informs your evidence collection; it doesn't determine the score.",
    "burn": "Policy age doesn't affect the finding? A three-year-old unreviewed security awareness policy in an evolving threat environment is worth investigating.",
    "roast": "Stale policies are often symptoms of stale programs. Investigate: is the training content current, is completion being tracked, and does the OSC have a process for reviewing their own policies? Then score."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "TRUE OR FALSE: If a CMMC assessment results in a 'Not Met' for any practice, the OSC automatically fails certification.",
    "opts": [
      "False — CMMC 2.0 allows a limited number of open POA&M items at the time of certification, provided specific conditions are met",
      "False — an OSC can self-certify regardless of Not Met findings",
      "True — any Not Met means certification is denied",
      "True — all 110 practices must be Met before certification is awarded"
    ],
    "ans": 0,
    "compliment": "POA&M AT CERTIFICATION: CONFIRMED. Not every Not Met is an immediate certification denial.",
    "praise": "CMMC 2.0 allows a limited number of open POA&M items at the time of certification — provided the practice is not among those that must be Met before certification, and the POA&M plan is credible. Not every Not Met is an automatic denial. The specific conditions and limitations are defined in the CMMC rule.",
    "burn": "Any Not Met = automatic failure? CMMC 2.0 was specifically designed to allow limited POA&M items at certification time.",
    "roast": "CMMC 1.0 was zero-tolerance. CMMC 2.0 deliberately changed this to allow limited POA&M items at certification — acknowledging that perfect implementation at certification time is unrealistic for the defense industrial base. Know the program you're assessing under."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "Which of the following statements about CMMC assessor conflicts of interest is TRUE?",
    "opts": [
      "An assessor who provided gap assessment services to an OSC six months ago may have an independence impairment that prevents them from conducting the formal certification assessment",
      "C3PAO independence requirements only apply to the lead assessor",
      "An assessor's employer's financial relationship with the OSC does not affect assessor independence",
      "An assessor can assess an organization they consulted for if more than one year has passed"
    ],
    "ans": 0,
    "compliment": "CONFLICT OF INTEREST IDENTIFIED. Prior consulting = independence concern regardless of time gap.",
    "praise": "An assessor who provided gap assessment or consulting services to an OSC has a potential independence impairment for the formal certification assessment — they would be assessing the implementation of advice they gave. The CYBER-AB independence requirements address this. Prior consulting relationships require disclosure and evaluation regardless of how much time has passed.",
    "burn": "One year resolves the conflict? Independence is about objectivity, not a time-based expiration.",
    "roast": "An assessor who helped an OSC implement their security program and then certifies it has assessed their own work. The conflict doesn't age out — it requires evaluation and disclosure. The C3PAO's quality management process handles this."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "Which of the following is a valid use of a POA&M item under CMMC 2.0?",
    "opts": [
      "To document a practice that is not yet fully implemented with a credible plan and timeline for completion",
      "To justify accepting a lower SPRS score permanently",
      "To replace evidence collection for practices where evidence is unavailable",
      "To document practices the OSC has decided not to implement"
    ],
    "ans": 0,
    "compliment": "VALID POA&M USE CONFIRMED. Documented gap with credible remediation plan — exactly right.",
    "praise": "A POA&M item documents a practice that is not yet fully implemented, with an identified gap, a credible remediation approach, and a realistic timeline. It is not a way to opt out of requirements, avoid evidence collection, or accept permanent non-compliance. A POA&M is a commitment to remediate.",
    "burn": "A POA&M documents practices the OSC decided not to implement? A POA&M is a remediation commitment — not an opt-out.",
    "roast": "POA&Ms that document permanent non-implementation, lack credible remediation plans, or repeatedly reschedule without progress are not compliant POA&Ms — they are documented non-compliance. A valid POA&M commits to fixing the gap."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "An OSC scores themselves 110 on their SPRS self-assessment but has no written SSP. What is the correct SPRS score they should have submitted?",
    "opts": [
      "Less than 110 — the absence of a written SSP is a Not Met finding on practice 3.12.4, which carries a point deduction",
      "Depends on whether a DoD assessment team has reviewed their environment",
      "110 — SSP documentation is a separate requirement from the assessment score",
      "110 — their controls are all implemented even without a written SSP"
    ],
    "ans": 0,
    "compliment": "NO SSP = NOT MET 3.12.4 = SCORE DEDUCTION. A perfect score requires all 110 practices including documentation.",
    "praise": "A 110 SPRS score means all 110 practices are implemented — including 3.12.4, which requires a written System Security Plan. An organization without a written SSP has Not Met 3.12.4 by definition. Their SPRS score should reflect that deduction. A 110 score with no SSP is a false attestation.",
    "burn": "Controls implemented without documentation still scores 110? Practice 3.12.4 requires a written SSP. No SSP = Not Met 3.12.4.",
    "roast": "You cannot score 110 and have no SSP. The SSP is practice 3.12.4 — it is one of the 110 requirements. An organization with no SSP has Not Met at minimum one practice, producing a maximum possible score less than 110."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "Which statement about CMMC reciprocity between US government frameworks is TRUE as of the CMMC 2.0 final rule?",
    "opts": [
      "ISO 27001 Level 2 provides CMMC Level 2 reciprocity",
      "SOC 2 Type II provides CMMC Level 2 reciprocity for cloud service providers",
      "FedRAMP High authorization provides automatic CMMC Level 3 equivalency",
      "There is no automatic reciprocity — organizations must undergo the CMMC assessment process regardless of other government framework authorizations"
    ],
    "ans": 3,
    "compliment": "NO AUTOMATIC RECIPROCITY. CMMC requires its own assessment regardless of other authorizations.",
    "praise": "CMMC 2.0 does not provide automatic reciprocity with FedRAMP, ISO 27001, SOC 2, or any other framework. Organizations must undergo the CMMC assessment process. FedRAMP authorization may reduce assessment burden for specific cloud environment practices — but it doesn't replace the CMMC assessment.",
    "burn": "FedRAMP High equals CMMC Level 3 automatically? The CMMC rule establishes its own assessment requirements with no automatic reciprocity provisions.",
    "roast": "Every framework has its own assessment purpose. FedRAMP assesses cloud providers for federal use. CMMC assesses defense contractors for CUI protection. These serve different purposes and neither automatically satisfies the other."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "Under CMMC 2.0, which entity is responsible for maintaining the official list of accredited C3PAOs?",
    "opts": [
      "The Department of Defense",
      "DCSA",
      "The Cyber Accreditation Body (CYBER-AB)",
      "NIST"
    ],
    "ans": 2,
    "compliment": "CYBER-AB: THE ACCREDITATION BODY. Not DoD, not NIST, not DCSA.",
    "praise": "The CYBER-AB (Cybersecurity Maturity Model Certification Accreditation Body) is the independent accreditation body responsible for accrediting C3PAOs and certifying individual assessors (CCAs/CCPs). The DoD defines the CMMC program; the CYBER-AB administers the assessor ecosystem.",
    "burn": "The DoD maintains the C3PAO list? The CYBER-AB is the independent accreditation body — separation of program ownership and assessor accreditation is intentional.",
    "roast": "DoD defines CMMC. CYBER-AB accredits the assessors. DCSA leads government assessments for Level 3. NIST writes the underlying standards. Four separate entities with four separate roles. Know which does what."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 4,
    "q": "An OSC's managed service provider (MSP) remotely administers the OSC's CUI environment using a dedicated jump host within the OSC's boundary, but the MSP's own network and SOC are external. How should the MSP's external SOC be scoped?",
    "opts": [
      "Out of Scope — only the jump host matters",
      "CUI Asset — the SOC monitors CUI traffic",
      "Security Protection Asset — the SOC provides security functions for the CUI environment",
      "CRMA — the MSP manages the risk externally"
    ],
    "ans": 2,
    "compliment": "SPA IDENTIFICATION ON AN MSP CHAIN! That is elite-level scoping!",
    "praise": "The MSP's external SOC provides a security function (monitoring, alerting) for the CUI environment even though it sits outside the OSC's physical boundary. Security Protection Assets don't need to store CUI — they need to provide security functions. The jump host is likely a CUI Asset; the SOC behind it is an SPA. You distinguished between the two. Impressive.",
    "burn": "You ignored the security function chain entirely. The SOC monitors the CUI environment — that's a security role, not an out-of-scope afterthought.",
    "roast": "An MSP's SOC that monitors CUI systems provides a security function for the CUI environment. Security Protection Assets include systems that provide security services even when external to the physical boundary. The monitoring function is the key — not the location."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 4,
    "q": "An OSC operates a DevSecOps CI/CD pipeline that builds, tests, and deploys code containing CUI technical data to a production CUI environment. The pipeline's build servers never store finished CUI artifacts for more than 60 seconds. How should the build servers be scoped?",
    "opts": [
      "Out of Scope — transient data under 60 seconds doesn't count",
      "CRMA — the OSC manages the transient risk",
      "CUI Asset — the pipeline processes CUI regardless of retention duration",
      "Specialized Asset — automated systems with unique characteristics"
    ],
    "ans": 2,
    "compliment": "CUI ASSET REGARDLESS OF RETENTION DURATION! Processing is processing — time is irrelevant!",
    "praise": "CUI Asset. Processing CUI technical data — even transiently — makes the build servers CUI Assets. There is no 'minimum retention threshold' in CMMC scoping. If the system receives, processes, or transmits CUI at any point, it processes CUI. The 60-second window is a red herring designed to test whether you'd apply a made-up exception. You didn't.",
    "burn": "Transient data doesn't count? Show me that exception in the scoping guidance. You won't find it because it doesn't exist.",
    "roast": "There is no minimum retention duration that exempts a system from CUI Asset classification. If the system processes CUI — even for one second — it is a CUI Asset. The question was designed to see if you'd invent an exception. Many candidates do."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 4,
    "q": "During a Level 2 assessment, you discover an OSC's backup system replicates encrypted CUI data to a geographically separate disaster recovery site operated by a different legal entity under the same parent company. How should the DR site be scoped?",
    "opts": [
      "Out of Scope — the data is encrypted and at a separate entity",
      "CRMA — the parent company manages the risk",
      "In scope — the DR site processes CUI and must be assessed or covered by the assessment boundary",
      "Specialized Asset — disaster recovery systems are always specialized"
    ],
    "ans": 2,
    "compliment": "DR SITE IN SCOPE. Encryption doesn't change the data classification, and legal entity boundaries don't override data flow boundaries!",
    "praise": "The DR site stores CUI — encrypted or not, the data is still CUI. A separate legal entity under the same parent doesn't create an automatic out-of-scope exemption. If the OSC's CUI flows there, it's in the assessment boundary. The DR site either needs its own CMMC assessment or must be included in the OSC's assessment scope. You followed the data, not the org chart.",
    "burn": "Encryption makes CUI not-CUI? Since when? And a different legal entity is still receiving and storing the OSC's CUI data.",
    "roast": "Encryption protects data in transit and at rest but does not change its classification. CUI replicated to a DR site — regardless of the operating entity — is still CUI. The assessment boundary follows the data flow, not the corporate structure."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 5,
    "q": "An OSC's assessment boundary includes an on-premises Active Directory (AD) that authenticates users to both CUI and non-CUI systems. During the assessment, you discover a federated trust relationship with a partner organization's AD that allows transitive authentication into the CUI environment. The partner's AD is not in the OSC's SSP. What is the correct assessor action?",
    "opts": [
      "Ignore it — the partner's AD is outside the OSC's boundary",
      "Document it as an observation but continue the assessment unchanged",
      "Flag it as a potential scope expansion requiring the OSC to update their SSP and assessment boundary before the assessment can validate the affected practices",
      "Immediately fail the assessment due to undocumented external dependencies"
    ],
    "ans": 2,
    "compliment": "SSP UPDATE REQUIRED BEFORE VALIDATION! You identified the scope gap AND the correct procedural response!",
    "praise": "A federated trust that allows transitive authentication into the CUI environment means the partner's AD provides an authentication path to CUI. The OSC's SSP must document this, and the assessment boundary may need expansion. You don't ignore it, you don't fail the entire assessment on the spot — you flag it as a scope gap requiring SSP remediation before those affected practices can be validated. That is precisely how a Lead Assessor handles a mid-assessment discovery.",
    "burn": "Ignoring an undocumented authentication path into the CUI environment is not an option. Neither is immediately failing the entire assessment without giving the OSC a chance to address the gap.",
    "roast": "Federated AD trusts that provide authentication paths into CUI environments must be documented in the SSP and potentially included in the assessment boundary. The correct action is to flag the gap, require SSP update, and assess affected practices after remediation — not ignore it or fail the entire assessment."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 5,
    "q": "An OSC claims their mobile device management (MDM) platform is out of scope because corporate phones only access email and never open CUI attachments. During evidence review, you discover the MDM policy allows personal app sideloading, the email DLP is configured to block CUI keywords but has a 6-month-old bypass exception for the VP of Engineering, and no containerization is enforced. What is the most accurate scoping determination?",
    "opts": [
      "Out of Scope — the DLP blocks CUI so the phones don't process it",
      "CRMA — the OSC manages mobile risk through MDM policies",
      "Security Protection Asset — the MDM provides security controls for mobile endpoints",
      "The MDM platform and enrolled devices should be assessed as potential CUI Assets given the DLP bypass exception creates an uncontrolled path for CUI to reach mobile devices"
    ],
    "ans": 3,
    "compliment": "DLP BYPASS EXCEPTION IDENTIFIED! You read the evidence, not the policy summary!",
    "praise": "The DLP bypass exception for the VP of Engineering creates an uncontrolled path for CUI to reach mobile devices. The OSC's claim that phones 'never open CUI attachments' is contradicted by their own MDM configuration. A bypass exception means the control isn't universal. Combined with no containerization and sideloading, you have mobile devices that could receive CUI without technical controls. The scoping claim fails the evidence test. This is why assessors review configurations, not just policy documents.",
    "burn": "You trusted the OSC's verbal claim over their own MDM configuration evidence. The DLP bypass exception for the VP of Engineering means CUI can reach mobile devices. Evidence over claims, always.",
    "roast": "A DLP bypass exception means the DLP is not uniformly enforced. If CUI can reach mobile devices through an exception path, the 'out of scope' claim is unsupported by evidence. Assessors must verify configurations against claims — and when they conflict, the configuration is the truth."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 4,
    "q": "Under 32 CFR Part 170, what happens if an OSC achieves a conditional CMMC Level 2 certification but fails to close all POA&M items within the allowed timeframe?",
    "opts": [
      "The certification is extended automatically for another 180 days",
      "The conditional certification becomes a full certification with documented exceptions",
      "The conditional certification expires and the OSC must restart the assessment process",
      "The C3PAO can unilaterally grant additional time based on remediation progress"
    ],
    "ans": 2,
    "compliment": "CONDITIONAL CERTIFICATION EXPIRATION! No extensions, no exceptions, no mercy!",
    "praise": "If POA&M items are not closed within the specified timeframe, the conditional certification expires. There is no automatic extension, no grandfathering, and no C3PAO authority to grant additional time. The OSC must restart the assessment process. This is by design — the conditional status is a time-limited path to compliance, not an indefinite holding pattern.",
    "burn": "Automatic extensions for POA&M failures? The entire point of the timeframe is that it's a hard deadline. Miss it and you start over.",
    "roast": "The 32 CFR Part 170 POA&M closure timeframe is a hard deadline. Failure to close items within the allowed period results in expiration of the conditional certification. The OSC must undergo a new assessment — there is no extension mechanism."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 4,
    "q": "Under DFARS 252.204-7012, when a contractor discovers a cyber incident, which of the following is NOT a required element of the incident report submitted to DoD?",
    "opts": [
      "A cyber incident report submitted via the DC3 portal",
      "Malicious software isolated and submitted to DoD Cyber Crime Center",
      "Images of affected information systems",
      "A complete remediation plan with projected costs and timeline"
    ],
    "ans": 3,
    "compliment": "REMEDIATION PLAN IS NOT A REPORTING REQUIREMENT! You know what's required vs. what's good practice!",
    "praise": "DFARS 7012 requires the incident report via DC3, preservation and submission of malicious software to DC3, and images of affected systems. It does NOT require a remediation plan with costs and timeline as part of the incident report. That may be good practice and contractually required elsewhere, but it's not in the 7012 reporting requirements. You distinguished between what the clause actually says and what people assume it says.",
    "burn": "A complete remediation plan with projected costs is not part of the DFARS 7012 incident reporting requirements. Reading the actual clause text matters.",
    "roast": "DFARS 7012 incident reporting requires: (1) report via DC3 within 72 hours, (2) malicious software submission to DC3, (3) system images preserved. Remediation planning is a separate activity — important, but not a clause-mandated reporting element."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 5,
    "q": "An OSC holds two active DoD contracts: Contract A explicitly includes DFARS 252.204-7012 and Contract B includes DFARS 252.204-7021 (the CMMC clause). Contract B requires CMMC Level 2. The OSC uses the same information system for both contracts. During assessment, the assessor discovers the SSP only references Contract B's CUI requirements. What is the regulatory impact?",
    "opts": [
      "No impact — CMMC Level 2 covers all DFARS 7012 requirements",
      "The assessment scope is insufficient because the SSP must address CUI from all contracts flowing through the assessed system",
      "The assessor should ignore Contract A since it's not subject to CMMC",
      "The C3PAO should assess both contracts simultaneously to save time"
    ],
    "ans": 1,
    "compliment": "SSP MUST ADDRESS ALL CUI SOURCES! You understand that assessment scope follows data, not individual contracts!",
    "praise": "When a single information system processes CUI from multiple contracts, the SSP must document all CUI data flows — not just the one triggering the CMMC assessment. An SSP that only references one contract's CUI requirements when the system handles CUI from multiple contracts is incomplete. The assessment boundary must account for all CUI processed by the in-scope systems, regardless of which contract triggered the assessment.",
    "burn": "Thinking CMMC Level 2 automatically covers all DFARS 7012 requirements ignores the fact that the SSP must accurately describe ALL CUI the system processes.",
    "roast": "An SSP must accurately describe the system's full CUI processing scope. If the system handles CUI from multiple contracts, all CUI flows must be documented. An incomplete SSP means the assessment cannot validate that all CUI is properly protected."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 4,
    "q": "Which regulatory document specifically defines the 110 security requirements that form the basis of CMMC Level 2?",
    "opts": [
      "NIST SP 800-53 Rev 5",
      "NIST SP 800-171 Rev 2",
      "DFARS 252.204-7012",
      "32 CFR Part 170"
    ],
    "ans": 1,
    "compliment": "NIST SP 800-171 REV 2! The 110 requirements that define Level 2!",
    "praise": "CMMC Level 2 is built on the 110 security requirements from NIST SP 800-171 Rev 2. Not SP 800-53 (which is a broader control catalog for federal systems), not DFARS 7012 (which references 800-171 but is a contract clause), and not 32 CFR Part 170 (which is the CMMC program rule). The question tests whether you know the source document, not just the program that uses it.",
    "burn": "Mixing up SP 800-171 with SP 800-53 or the CMMC rule itself is a fundamental knowledge gap for any assessor.",
    "roast": "CMMC Level 2 = NIST SP 800-171 Rev 2's 110 security requirements. SP 800-53 is the broader federal control catalog. DFARS 7012 is the contract clause that requires 800-171 implementation. 32 CFR Part 170 is the CMMC program rule. Different documents, different purposes."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 4,
    "q": "During a CMMC Level 2 assessment, the OSC presents a System Security Plan (SSP) that was last updated 14 months ago. The CISO states that 'nothing has changed.' What is the correct assessor response?",
    "opts": [
      "Accept the SSP as current since the CISO confirmed no changes",
      "Document the stale SSP date but proceed with the assessment using it as-is",
      "Require evidence that the SSP review process is active and verify whether system changes occurred since the last update",
      "Immediately halt the assessment until the SSP is updated within the last 90 days"
    ],
    "ans": 2,
    "compliment": "VERIFY THE CLAIM, DON'T ACCEPT IT! Evidence over assurance — every time!",
    "praise": "'Nothing has changed' is an assurance, not evidence. The assessor must verify the claim against change management records, configuration baselines, and other artifacts. If the system truly hasn't changed, the SSP may be acceptable — but the assessor needs evidence of that. A 14-month-old SSP could be fine or catastrophically outdated. The answer is in the evidence, not the CISO's word.",
    "burn": "Accepting 'nothing has changed' at face value is not assessment — it's rubber-stamping. Verify the claim against evidence.",
    "roast": "CMMC assessors verify, not trust. A stale SSP requires the assessor to examine change management records and configuration evidence to confirm whether the SSP still accurately reflects the system. 'Nothing has changed' must be corroborated."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 4,
    "q": "An OSC's POA&M lists an open item for Practice AC.L2-3.1.1 (Authorized Access Control) with a target closure date that has already passed by 45 days. The OSC says the remediation is 'almost done.' How should the assessor handle this for the CMMC assessment?",
    "opts": [
      "Accept the POA&M item as-is since remediation is in progress",
      "Mark the practice as MET since the OSC has a plan",
      "Mark the practice as NOT MET — an overdue POA&M item without completed remediation means the practice is not implemented",
      "Extend the POA&M deadline by another 90 days at the assessor's discretion"
    ],
    "ans": 2,
    "compliment": "NOT MET! An overdue, unclosed POA&M item means the practice isn't implemented!",
    "praise": "An overdue POA&M item with incomplete remediation means the practice is not implemented as of the assessment date. The assessor cannot extend deadlines or accept 'almost done' as implementation. POA&M items show awareness of a gap — they don't satisfy the practice requirement. NOT MET is the only defensible finding. The OSC can address it and seek reassessment.",
    "burn": "'Almost done' is not 'done.' An overdue POA&M item with incomplete remediation is a NOT MET finding. Assessors don't grant extensions.",
    "roast": "POA&M items document known gaps. An overdue item with incomplete remediation means the practice is not implemented. Assessors evaluate current state, not future intent. NOT MET — the OSC can remediate and reassess."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 5,
    "q": "You are conducting a CMMC Level 2 assessment and discover that the OSC's incident response plan references NIST SP 800-61 procedures but the plan has never been tested or exercised. The OSC has IR.L2-3.6.1 (Incident Handling), IR.L2-3.6.2 (Incident Reporting), and IR.L2-3.6.3 (Incident Response Testing) in scope. Which practices can be marked MET?",
    "opts": [
      "All three — having a documented plan that references NIST guidance satisfies the practices",
      "IR.L2-3.6.1 and IR.L2-3.6.2 only — testing is separate from having and reporting procedures",
      "IR.L2-3.6.1 only — without testing, you cannot verify the reporting procedures work either",
      "None — an untested IR plan cannot be considered implemented for any IR practice"
    ],
    "ans": 1,
    "compliment": "3.6.1 AND 3.6.2 MET, BUT 3.6.3 NOT MET! You parsed each practice independently!",
    "praise": "IR.L2-3.6.1 requires incident handling capability (the plan exists and defines procedures). IR.L2-3.6.2 requires incident tracking and reporting mechanisms (which can exist independently of testing). IR.L2-3.6.3 specifically requires testing the incident response capability. Each practice has its own assessment criteria. The plan satisfies 3.6.1 and 3.6.2; the absence of testing only directly fails 3.6.3. You assessed each practice on its own merits.",
    "burn": "Either marking all three MET or none MET shows you're not evaluating each practice against its specific requirements.",
    "roast": "Each CMMC practice has specific assessment objectives. A documented IR plan can satisfy the 'establish procedures' and 'track/report' practices even if testing hasn't occurred. Testing is its own practice with its own requirement. Assess each practice independently."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 5,
    "q": "During evidence collection for Practice AU.L2-3.3.1 (System Auditing), the OSC provides audit logs from their SIEM. You notice the logs show a 72-hour gap from three weeks ago with no explanation in the OSC's documentation. The OSC's IT admin says 'the SIEM was being patched.' What should the assessor do?",
    "opts": [
      "Accept the explanation — SIEM patching is a normal maintenance activity",
      "Document the gap as an observation but mark the practice MET since auditing is generally functional",
      "Investigate further: request change management records for the SIEM maintenance, verify the gap duration matches a patch window, and determine if compensating log sources existed during the outage",
      "Mark the practice NOT MET solely due to the 72-hour log gap"
    ],
    "ans": 2,
    "compliment": "INVESTIGATE FURTHER! A 72-hour gap requires corroboration, not acceptance!",
    "praise": "A 72-hour audit log gap is significant and requires investigation — not automatic acceptance or automatic failure. The assessor should: (1) request change management records to verify planned maintenance, (2) compare the gap duration to the stated patch window, (3) determine if alternative log sources captured events during the outage. A planned, documented maintenance window with compensating controls is very different from an unexplained gap. The evidence determines the finding, not the verbal explanation.",
    "burn": "Accepting 'we were patching' without change management evidence is not assessment. And automatically failing without investigation is equally lazy.",
    "roast": "Audit log gaps require investigation, not assumptions. Verify the maintenance claim against change records, assess the gap duration's reasonableness, and check for compensating controls. The assessor's job is to determine facts through evidence, not to accept or reject claims at face value."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 3,
    "q": "An OSC tells you they are 'CMMC Level 2 compliant' because they completed a self-assessment and uploaded their score to SPRS. Are they correct?",
    "opts": [
      "Yes — a self-assessment with SPRS upload satisfies CMMC Level 2",
      "No — CMMC Level 2 requires a C3PAO assessment, not a self-assessment",
      "Yes — but only if their SPRS score is 110",
      "No — SPRS scores are not related to CMMC"
    ],
    "ans": 1,
    "compliment": "C3PAO ASSESSMENT REQUIRED! Self-assessment is NOT CMMC Level 2 certification!",
    "praise": "CMMC Level 2 requires a third-party assessment by an accredited C3PAO. A self-assessment uploaded to SPRS satisfies the DFARS 7019 interim requirement but does NOT constitute CMMC Level 2 certification. These are two different things. Many contractors confuse SPRS self-assessment with CMMC certification — and many assessors let them. You didn't.",
    "burn": "A self-assessment is not a CMMC assessment. SPRS upload satisfies DFARS 7019 interim requirements, not CMMC Level 2 certification.",
    "roast": "CMMC Level 2 certification requires a C3PAO assessment. Self-assessments with SPRS upload meet DFARS 252.204-7019 (interim) requirements. Different clauses, different requirements, different outcomes. Never conflate them."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 4,
    "q": "During a CMMC assessment, the OSC's CISO presents a beautifully formatted System Security Plan with 150 pages of detailed control descriptions. You notice every control description uses identical language from NIST SP 800-171A assessment objectives, word for word, with no organization-specific implementation details. What should this tell the assessor?",
    "opts": [
      "The OSC has excellent documentation practices aligned with NIST",
      "The SSP is likely a template that hasn't been customized — it describes what should be done, not what the OSC actually does",
      "The SSP is compliant because it uses official NIST language",
      "This level of detail exceeds CMMC requirements and demonstrates maturity"
    ],
    "ans": 1,
    "compliment": "TEMPLATE DETECTION! You recognized that NIST language without implementation details is a red flag!",
    "praise": "An SSP that copies NIST assessment objective language verbatim without organization-specific implementation details is a template, not a system security plan. A real SSP describes HOW the organization implements each requirement — specific tools, configurations, personnel, procedures. Generic language that could apply to any organization is a documentation exercise, not evidence of implementation. You've seen this before. You know the difference.",
    "burn": "An SSP that copies NIST language word-for-word without any organization-specific details is a template. It tells you what should be done, not what IS done.",
    "roast": "System Security Plans must describe the organization's actual implementation — specific tools, configurations, responsibilities. Verbatim NIST language without customization indicates a template that hasn't been adapted to the organization's real environment."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 4,
    "q": "An OSC claims they satisfy Practice MP.L2-3.8.3 (Media Marking) because they have a policy requiring CUI markings. During your assessment, you observe 15 USB drives in the IT storage room, none of which have CUI markings. The IT admin says 'those are blank drives waiting to be issued.' What is the correct assessment approach?",
    "opts": [
      "Mark the practice MET — the policy exists and blank drives don't need markings",
      "Mark the practice NOT MET — physical media without markings violates the practice",
      "Verify whether the drives are truly blank, check whether issued drives are marked, and assess the full marking lifecycle including issuance, use, and sanitization procedures",
      "Accept the IT admin's explanation and move on — the policy satisfies the requirement"
    ],
    "ans": 2,
    "compliment": "FULL LIFECYCLE ASSESSMENT! You didn't stop at the policy OR the unmarked drives!",
    "praise": "Neither the policy alone nor the unmarked drives alone tell the full story. The assessor must verify the claim (are the drives truly blank?), assess the marking process for drives in active use, and evaluate the full media lifecycle. A policy that requires markings is necessary but not sufficient. Unmarked blank drives aren't automatically a finding if the issuance process includes marking. But you need to verify that process exists and functions. Assessment means investigating, not assuming.",
    "burn": "You either stopped at the policy or stopped at the unmarked drives. The correct approach examines the full media marking lifecycle.",
    "roast": "Media marking assessment requires evaluating the full lifecycle: policy, implementation during issuance, marking of active media, and handling of retired media. Neither a policy alone nor a single observation is sufficient for a determination."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 5,
    "q": "You are a CMMC Lead Assessor finalizing your assessment report. Your team assessed 110 practices. For Practice SC.L2-3.13.11 (CUI Encryption), the OSC uses FIPS-validated encryption for data at rest and in transit EXCEPT for one legacy application that transmits CUI over TLS 1.0 between two internal servers. The OSC has a POA&M to upgrade the application within 90 days. Under CMMC 2.0 scoring methodology, what is the impact?",
    "opts": [
      "No impact — TLS 1.0 is still encryption and the POA&M covers the gap",
      "The practice receives a NOT MET finding — TLS 1.0 is not FIPS-validated cryptography, and the POA&M can enable conditional certification but doesn't change the finding",
      "The practice is MET with conditions since 'most' of the environment uses proper encryption",
      "The entire assessment fails because encryption is a critical practice that cannot be on a POA&M"
    ],
    "ans": 1,
    "compliment": "NOT MET WITH POA&M ELIGIBILITY! TLS 1.0 fails the FIPS requirement, and you correctly identified that a POA&M doesn't change the finding — it enables conditional status!",
    "praise": "TLS 1.0 does not satisfy FIPS-validated cryptography requirements. The practice is NOT MET. However, if the POA&M meets the criteria for conditional certification (the practice is not in the excluded set, the remediation is achievable within the timeframe), the OSC can receive conditional status. The key distinction: the POA&M doesn't make the practice MET — it allows the assessment to proceed with a conditional outcome. You understood both the technical finding and the procedural mechanism.",
    "burn": "TLS 1.0 is not FIPS-validated cryptography. The practice is NOT MET regardless of the POA&M. The POA&M enables conditional certification, not a MET finding.",
    "roast": "FIPS-validated cryptography excludes TLS 1.0. A POA&M for the gap enables conditional certification but does not change the practice finding from NOT MET to MET. Understanding the distinction between 'the finding' and 'the certification outcome' is critical for Lead Assessors."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 5,
    "q": "Two C3PAOs assess identical OSCs with identical implementations. C3PAO Alpha marks Practice AC.L2-3.1.3 (CUI Flow Control) as MET. C3PAO Bravo marks the same practice as NOT MET for an identical implementation. Both C3PAOs submit their assessment results. Under CMMC 2.0, which statement is most accurate?",
    "opts": [
      "This is impossible — CMMC assessment criteria are objective and would always produce the same result",
      "This is a normal outcome — assessor professional judgment means reasonable people can disagree",
      "This indicates a quality problem — the CMMC ecosystem relies on consistency, and the CYBER-AB's quality management processes should identify and address such discrepancies",
      "Both findings are valid because CMMC allows C3PAOs to set their own assessment standards"
    ],
    "ans": 2,
    "compliment": "QUALITY MANAGEMENT IDENTIFICATION! You understand why ecosystem consistency matters!",
    "praise": "While some degree of professional judgment exists in any assessment framework, the CMMC program is designed for consistency across C3PAOs. Opposing findings on identical implementations indicate a quality issue that the CYBER-AB's oversight processes — including quality audits of C3PAOs — should identify and address. It's not 'impossible' (human judgment varies), it's not 'normal' (the framework aims for consistency), and C3PAOs don't set their own standards (they follow CMMC assessment guidance). You identified the systemic mechanism for handling this.",
    "burn": "Opposite findings on identical implementations isn't 'normal professional judgment' — it's a quality control problem that the ecosystem is designed to catch.",
    "roast": "CMMC assessment consistency is maintained through the CYBER-AB's quality management of C3PAOs. Opposing findings on identical implementations trigger quality review processes. The framework accepts some professional judgment but aims for reproducible, consistent outcomes."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 4,
    "type": "multi",
    "q": "An OSC's network includes the following systems. Select ALL that would be classified as Security Protection Assets (SPAs) under CMMC scoping guidance:",
    "opts": [
      "SIEM server that collects and correlates logs from CUI systems",
      "Network firewall between the CUI enclave and the internet",
      "File server that stores CUI engineering drawings",
      "Domain controller that provides authentication to CUI and non-CUI systems",
      "Vulnerability scanner used exclusively on CUI systems"
    ],
    "ans": [
      0,
      1,
      4
    ],
    "compliment": "TRIPLE SPA IDENTIFICATION! You distinguished security function from data storage with precision!",
    "praise": "The SIEM (log correlation), firewall (boundary protection), and vulnerability scanner (security assessment) all provide security functions FOR the CUI environment without storing CUI themselves — they are SPAs. The file server stores CUI — it's a CUI Asset. The domain controller provides authentication to both CUI and non-CUI systems — it's also a CUI Asset (or at minimum an SPA, but its authentication role for CUI systems makes it more accurately a CUI Asset). You parsed each system's function correctly.",
    "burn": "You confused systems that PROTECT CUI with systems that STORE CUI. Security Protection Assets provide security services — they don't hold the data.",
    "roast": "SPAs provide security functions (monitoring, filtering, scanning) for the CUI environment. Systems that store, process, or transmit CUI are CUI Assets. The distinction is function vs. data handling."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 4,
    "type": "multi",
    "q": "During a CMMC Level 2 assessment, which of the following constitute valid evidence for Practice PE.L2-3.10.1 (Physical Access Authorizations)? Select ALL that apply:",
    "opts": [
      "A policy document stating 'physical access is controlled'",
      "A current list of personnel authorized for facility access, reviewed quarterly",
      "Visitor logs showing escort procedures for the last 6 months",
      "Badge reader access logs showing only authorized personnel entered CUI areas",
      "An email from the facilities manager confirming access is restricted"
    ],
    "ans": [
      1,
      2,
      3
    ],
    "compliment": "THREE VALID EVIDENCE TYPES! You identified what demonstrates implementation vs. what just claims it!",
    "praise": "Valid evidence includes: (1) the authorized personnel list with review dates — shows who is authorized and that the list is maintained, (2) visitor logs with escort records — shows the process functions for non-authorized personnel, (3) badge reader logs — shows technical enforcement of the authorization. A generic policy statement and an email confirmation are claims, not evidence of implementation. Evidence must demonstrate that the practice is operating, not just that someone says it is.",
    "burn": "A policy statement and an email are not evidence of implementation — they're claims. Evidence must demonstrate the practice is actually operating.",
    "roast": "CMMC evidence must demonstrate implementation, not intent. Personnel lists, visitor logs, and access logs show the practice functioning. Policy documents and verbal/email confirmations show awareness, not implementation."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "Under NIST SP 800-171, Practice 3.13.11 requires the use of FIPS-validated cryptography when protecting CUI. Which of the following correctly describes this requirement?",
    "opts": [
      "Any encryption algorithm is acceptable as long as the key length is at least 256 bits",
      "The cryptographic module must be validated under FIPS 140-2 or FIPS 140-3 by an accredited lab",
      "Only AES-256 meets the FIPS validation requirement",
      "FIPS validation is recommended but not required for Level 2 assessments"
    ],
    "ans": 1,
    "compliment": "FIPS FUNDAMENTALS LOCKED DOWN! You know exactly what FIPS validation means!",
    "praise": "FIPS validation means the cryptographic MODULE has been tested and validated by a CMVP-accredited lab under FIPS 140-2 or FIPS 140-3. It is not about a specific algorithm or key length — it is about the module itself being certified. AES-256 is commonly used, but the validation applies to the module, not the algorithm alone. And it is absolutely required, not optional, for CMMC Level 2.",
    "burn": "FIPS validation is about the MODULE, not the algorithm. Go read the CMVP.",
    "roast": "FIPS-validated cryptography means the cryptographic module itself has been validated by an accredited lab under FIPS 140-2/140-3. Not the algorithm alone, and definitely not optional."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 2,
    "q": "An OSC uses BitLocker with a FIPS-validated configuration to encrypt all laptops that store CUI. During scoping, how should the BitLocker key management server be classified?",
    "opts": [
      "Out of Scope — BitLocker is a Microsoft product, not an OSC asset",
      "Security Protection Asset — it protects CUI assets but does not process CUI directly",
      "CUI Asset — it has access to encrypted CUI data",
      "CRMA — the OSC manages the risk internally"
    ],
    "ans": 1,
    "compliment": "SECURITY PROTECTION ASSET! You nailed the key management scoping!",
    "praise": "The BitLocker key management server is a Security Protection Asset. It does not store or process CUI directly, but it provides critical security functions (encryption key management) that protect CUI assets. Without it, the encryption protecting CUI would be compromised. This is a textbook SPA classification.",
    "burn": "The key management server protects CUI assets — that makes it an SPA, not out of scope.",
    "roast": "A key management server provides security functions for CUI protection. That is the definition of a Security Protection Asset — not a CUI Asset, not out of scope."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During a CMMC Level 2 assessment, you ask the OSC about their encryption implementation for CUI at rest. They tell you they use AES-256 encryption. What is your most important follow-up question?",
    "opts": [
      "What key length do you use for the encryption?",
      "Is the cryptographic module FIPS 140-2 or FIPS 140-3 validated?",
      "Do you also encrypt CUI in transit?",
      "How often do you rotate the encryption keys?"
    ],
    "ans": 1,
    "compliment": "FOLLOW-UP MASTERY! You went straight for the FIPS validation question!",
    "praise": "The most critical follow-up is confirming FIPS validation of the cryptographic module. Many organizations use AES-256 but through modules that are NOT FIPS validated. The algorithm being strong is not enough — the module must be validated. Key length was already stated (256-bit). Transit encryption and key rotation are important but secondary to the fundamental FIPS requirement.",
    "burn": "AES-256 is great, but is the MODULE validated? That is the assessor question.",
    "roast": "Using AES-256 does not automatically mean FIPS compliance. The cryptographic module must be FIPS 140-2 or 140-3 validated — that is the first thing an assessor should verify."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "NIST SP 800-171 Practice 3.13.8 requires implementing cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission. Which scenario satisfies this requirement?",
    "opts": [
      "Using HTTPS with TLS 1.0 for all web-based CUI access",
      "Sending CUI via email with a password-protected ZIP attachment",
      "Using TLS 1.2 or higher with FIPS-validated cryptographic modules for all CUI transmissions",
      "Encrypting CUI files before emailing them using a consumer-grade encryption tool"
    ],
    "ans": 2,
    "compliment": "TLS MASTERY! You know exactly what transit encryption requires!",
    "praise": "TLS 1.2 or higher with FIPS-validated modules is the correct answer. TLS 1.0 is deprecated and has known vulnerabilities. Password-protected ZIPs and consumer-grade tools are not FIPS-validated cryptographic mechanisms. The requirement is clear: FIPS-validated cryptography for CUI in transit.",
    "burn": "TLS 1.0? In this economy? Deprecated since 2020. FIPS-validated TLS 1.2+ is the standard.",
    "roast": "CUI in transit requires FIPS-validated cryptographic mechanisms. TLS 1.2+ with validated modules is the standard. TLS 1.0 is deprecated, and consumer tools lack FIPS validation."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA",
    "diff": 3,
    "q": "An OSC claims they meet Practice 3.13.11 (FIPS-validated cryptography) because they use OpenSSL for all encryption operations. Is this claim valid?",
    "opts": [
      "Yes — OpenSSL is widely trusted and open source, which exceeds FIPS requirements",
      "Yes — OpenSSL has a FIPS module that is validated, so all OpenSSL usage is compliant",
      "No — only specific versions of OpenSSL with the FIPS Object Module enabled and properly configured are FIPS validated",
      "No — open source cryptography can never be FIPS validated"
    ],
    "ans": 2,
    "compliment": "OPENSSL GOTCHA DODGED! You know the nuance that trips up most people!",
    "praise": "This is a classic gotcha. OpenSSL itself is not FIPS validated — only specific versions with the FIPS Object Module (FOM) enabled and properly configured have FIPS validation. Using OpenSSL without the FOM enabled does not meet 3.13.11. Many organizations make this mistake, assuming that using OpenSSL equals FIPS compliance.",
    "burn": "OpenSSL does not equal FIPS. Only the FIPS Object Module in specific versions is validated.",
    "roast": "Using OpenSSL does not automatically mean FIPS compliance. Only specific versions with the FIPS Object Module properly enabled carry FIPS 140-2/140-3 validation. Default OpenSSL configurations are NOT FIPS validated."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "You are assessing an OSC and discover they use a Hardware Security Module (HSM) for key management. Which aspect of the HSM deployment is most critical to verify for CMMC compliance?",
    "opts": [
      "That the HSM is manufactured by a reputable vendor",
      "That the HSM has its own FIPS 140-2 Level 2 or higher validation certificate",
      "That the HSM is stored in a locked server room",
      "That the HSM firmware is updated to the latest version"
    ],
    "ans": 1,
    "compliment": "HSM EXPERT! You zeroed in on the validation certificate!",
    "praise": "The FIPS 140-2 (or 140-3) validation certificate of the HSM itself is the critical verification point. HSMs are purpose-built for cryptographic operations, but not all HSMs are FIPS validated, and validation levels matter. Physical security and firmware updates are good practices, but without the FIPS validation certificate, the HSM cannot satisfy the cryptographic requirements.",
    "burn": "A fancy HSM without a FIPS validation certificate is just expensive hardware.",
    "roast": "An HSM must have its own FIPS 140-2 Level 2+ validation certificate. Vendor reputation and physical security are important but secondary to the validation certificate requirement."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 3,
    "q": "An OSC uses a VPN appliance that encrypts all CUI traffic between remote offices using FIPS-validated cryptography. How should this VPN appliance be scoped?",
    "opts": [
      "Out of Scope — VPNs are network infrastructure, not CUI systems",
      "CUI Asset — it processes encrypted CUI traffic",
      "Security Protection Asset — it provides cryptographic protection for CUI in transit",
      "CRMA — the VPN vendor manages the encryption"
    ],
    "ans": 2,
    "compliment": "VPN SCOPING PERFECTION! Security Protection Asset for the win!",
    "praise": "The VPN appliance is a Security Protection Asset. It provides cryptographic protection for CUI in transit between sites. It does not store or process CUI itself — it encrypts the traffic carrying CUI. This is a security function that protects CUI assets, making it an SPA. The vendor managing the product does not make it a CRMA.",
    "burn": "A VPN encrypting CUI traffic is a Security Protection Asset. It protects CUI — that is its purpose.",
    "roast": "A VPN appliance providing FIPS-validated encryption for CUI traffic is a Security Protection Asset. It provides security functions for CUI protection without directly processing CUI itself."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 2,
    "q": "Under NIST SP 800-171, Practice 3.13.10 addresses key management. Which of the following is a fundamental requirement for cryptographic key management?",
    "opts": [
      "Keys must be stored in a separate physical location from the encrypted data",
      "Keys must be produced, controlled, and distributed using approved mechanisms",
      "All encryption keys must be rotated every 30 days",
      "Key management must be handled exclusively by a dedicated security team"
    ],
    "ans": 1,
    "compliment": "KEY MANAGEMENT FUNDAMENTALS! You know the core requirement!",
    "praise": "Practice 3.13.10 requires establishing and managing cryptographic keys using approved key management technology and processes. Keys must be produced, controlled, and distributed through mechanisms that ensure their security. Specific rotation schedules and staffing are organizational decisions, not universal requirements. Physical separation is good practice but not the core requirement.",
    "burn": "Key management is about production, control, and distribution — not just where you store them.",
    "roast": "Cryptographic key management under 3.13.10 requires keys to be produced, controlled, and distributed using approved mechanisms. Rotation schedules and staffing are implementation details, not the fundamental requirement."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA",
    "diff": 2,
    "q": "An OSC encrypts all CUI at rest on their file servers using full disk encryption (FDE). They claim this satisfies Practice 3.13.16 (protecting CUI at rest). What is the potential issue with this claim?",
    "opts": [
      "Full disk encryption does not protect CUI from authorized users who can access the decrypted volume",
      "Full disk encryption is not allowed under NIST SP 800-171",
      "FDE only works on Windows systems, not Linux",
      "Full disk encryption is too slow for server environments"
    ],
    "ans": 0,
    "compliment": "FDE GOTCHA SPOTTED! You understand the limitations of full disk encryption!",
    "praise": "The gotcha with full disk encryption is that once the system is booted and the volume is decrypted, authorized users have access to all data on that volume. FDE primarily protects against physical theft of powered-off devices. For CUI at rest, additional file-level or database-level encryption may be needed to protect against insider threats or unauthorized access on running systems.",
    "burn": "FDE protects against theft of powered-off devices, not against authorized users on running systems.",
    "roast": "Full disk encryption protects against physical theft when a device is powered off. Once booted, all authorized users can access the decrypted volume. Additional controls like file-level encryption may be needed for comprehensive CUI at-rest protection."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 4,
    "q": "During assessment evidence collection for Practice 3.13.11 (FIPS-validated cryptography), which combination of artifacts provides the strongest evidence of compliance?",
    "opts": [
      "A policy stating FIPS is required and a vendor brochure showing the product supports AES-256",
      "The CMVP validation certificate number, system configuration screenshots showing FIPS mode enabled, and audit logs showing no non-FIPS algorithms in use",
      "An email from the IT director confirming FIPS compliance and a network diagram showing encryption points",
      "Purchase receipts for FIPS-validated products and a signed attestation from the CISO"
    ],
    "ans": 1,
    "compliment": "EVIDENCE GOLD STANDARD! You know what real FIPS evidence looks like!",
    "praise": "The strongest evidence combines: (1) the CMVP validation certificate — proves the specific module is validated, (2) configuration screenshots showing FIPS mode is actually enabled — proves it is operational, (3) audit logs showing no non-FIPS algorithms — proves ongoing compliance. Policies, emails, and purchase receipts are supporting documents but do not demonstrate operational implementation.",
    "burn": "Policies and emails are claims. CMVP certificates and configs are evidence.",
    "roast": "Strong FIPS evidence requires the validation certificate, proof that FIPS mode is enabled in configuration, and audit evidence of ongoing compliance. Policies and attestations are claims, not operational evidence."
  },
  {
    "cat": "scope",
    "catLabel": "SCOPING",
    "diff": 4,
    "q": "An OSC has a PKI infrastructure with a root Certificate Authority (CA) that issues certificates used to authenticate users accessing CUI systems. The root CA is air-gapped and only brought online for certificate operations. How should this root CA be scoped?",
    "opts": [
      "Out of Scope — it is air-gapped and never touches CUI",
      "CUI Asset — it issues certificates for CUI systems",
      "Security Protection Asset — it provides authentication infrastructure that protects CUI access",
      "Specialized Asset — air-gapped systems require tailored assessment"
    ],
    "ans": 2,
    "compliment": "PKI SCOPING MASTER! Root CA as SPA — that is expert-level scoping!",
    "praise": "The root CA is a Security Protection Asset. While air-gapped and not directly processing CUI, it provides the foundational trust anchor for the PKI that authenticates users accessing CUI systems. Without it, the entire certificate-based authentication chain would be compromised. Air-gapping is a security control, not a scoping exemption.",
    "burn": "Air-gapped does not mean out of scope when the asset provides security functions for CUI systems.",
    "roast": "An air-gapped root CA that issues certificates for CUI system authentication is a Security Protection Asset. The air gap is a security control, not a scoping exemption. It provides critical security infrastructure for CUI protection."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA",
    "diff": 4,
    "q": "An OSC says they meet the encryption at rest requirement because their cloud storage provider (AWS S3) encrypts all data by default with SSE-S3. As an assessor, what is the critical issue with this claim?",
    "opts": [
      "AWS S3 default encryption does not use AES-256",
      "The OSC must verify that the specific S3 encryption module is FIPS validated and that they have configured it in FIPS mode, not just rely on default settings",
      "Cloud storage encryption can never meet CMMC requirements",
      "Default encryption is always sufficient because AWS manages the FIPS compliance"
    ],
    "ans": 1,
    "compliment": "CLOUD ENCRYPTION GOTCHA DESTROYED! You know the difference between default and compliant!",
    "praise": "The critical issue is FIPS validation verification. AWS S3 does support FIPS-validated endpoints, but the OSC must verify their specific configuration uses FIPS-validated modules and that they connect via FIPS endpoints. Default encryption settings and FIPS-validated encryption are not the same thing. The OSC must demonstrate they have specifically configured for FIPS compliance, not just rely on defaults.",
    "burn": "Default cloud encryption and FIPS-validated encryption are not the same thing. Verify the configuration.",
    "roast": "AWS S3 default encryption (SSE-S3) uses AES-256, but the OSC must verify FIPS validation of the specific module and configure FIPS endpoints. Default does not equal FIPS compliant — the assessor must see evidence of FIPS-specific configuration."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "Under NIST SP 800-171, what is the relationship between Practice 3.13.8 (encryption in transit) and Practice 3.13.11 (FIPS-validated cryptography)?",
    "opts": [
      "They are unrelated — 3.13.8 covers transit and 3.13.11 covers storage",
      "3.13.11 supersedes 3.13.8, so only FIPS validation needs to be assessed",
      "3.13.8 requires encryption for CUI in transit, and 3.13.11 requires that the encryption used must be FIPS-validated — they work together",
      "3.13.8 is optional if 3.13.11 is fully implemented"
    ],
    "ans": 2,
    "compliment": "PRACTICE RELATIONSHIP NAILED! You understand how these practices interconnect!",
    "praise": "These practices work together. 3.13.8 establishes the requirement to use cryptographic mechanisms for CUI in transit. 3.13.11 requires that any cryptography used (whether for transit or at rest) must be FIPS validated. You cannot satisfy 3.13.8 without also considering 3.13.11 — the encryption used for transit must be FIPS validated.",
    "burn": "These practices are interrelated, not independent. The encryption in 3.13.8 must be FIPS validated per 3.13.11.",
    "roast": "Practice 3.13.8 requires encryption for CUI in transit, and 3.13.11 requires all cryptography to be FIPS validated. They are complementary — transit encryption must use FIPS-validated modules."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "FIPS 140-2 is being superseded by FIPS 140-3. Which of the following best describes a key difference between the two standards?",
    "opts": [
      "FIPS 140-3 eliminates the requirement for third-party lab testing of cryptographic modules",
      "FIPS 140-3 aligns with ISO/IEC 19790 and ISO/IEC 24759 international standards, replacing the FIPS 140-2 framework with a globally harmonized approach",
      "FIPS 140-3 only applies to software modules, not hardware",
      "FIPS 140-3 removes all security levels and replaces them with a single pass/fail grade"
    ],
    "ans": 1,
    "compliment": "FIPS 140-3 TRANSITION KNOWLEDGE ON POINT! You understand the international alignment shift!",
    "praise": "FIPS 140-3 aligns the U.S. cryptographic module validation program with international standards ISO/IEC 19790 (security requirements) and ISO/IEC 24759 (test requirements). This is a major structural change from 140-2, which was a standalone U.S. standard. Third-party lab testing is still required. All four security levels are retained. The standard applies to hardware, software, and firmware modules. FIPS 140-2 certifications will sunset on September 21, 2026 — after that date, only FIPS 140-3 validations will be accepted for new submissions.",
    "burn": "FIPS 140-3 doesn't eliminate lab testing or security levels. It aligns with ISO standards — that's the structural change.",
    "roast": "FIPS 140-3 adopts ISO/IEC 19790 and 24759 as its foundation. Lab testing remains mandatory. Security levels 1–4 still exist. The change is international harmonization, not simplification."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 3,
    "q": "An OSC's cryptographic module holds a FIPS 140-2 validation certificate. With FIPS 140-2 sunsetting on September 21, 2026, what happens to their existing validation?",
    "opts": [
      "All FIPS 140-2 certificates are immediately revoked on the sunset date",
      "FIPS 140-2 validated modules can continue to be used after the sunset date, but no new FIPS 140-2 validations will be accepted — organizations should plan their transition to FIPS 140-3",
      "FIPS 140-2 certificates automatically convert to FIPS 140-3 certificates",
      "The OSC must immediately replace all FIPS 140-2 modules before the sunset date"
    ],
    "ans": 1,
    "compliment": "SUNSET TRANSITION UNDERSTOOD! You know the difference between 'no new validations' and 'revoked'!",
    "praise": "After the FIPS 140-2 sunset date of September 21, 2026, CMVP will no longer accept new FIPS 140-2 validation submissions. Existing FIPS 140-2 validated modules remain valid and can continue to be used — they are not revoked. However, organizations should plan their transition to FIPS 140-3 validated modules for long-term compliance. Certificates do not auto-convert; a new validation under FIPS 140-3 requires a separate testing and certification process.",
    "burn": "FIPS 140-2 certificates don't auto-convert or get revoked on the sunset date. No new submissions — existing ones remain valid.",
    "roast": "The FIPS 140-2 sunset means CMVP stops accepting new 140-2 submissions after September 21, 2026. Existing validations remain valid. No auto-conversion. No immediate revocation. Plan the transition, don't panic."
  },
  {
    "cat": "trick",
    "catLabel": "GOTCHA ROUND",
    "diff": 4,
    "q": "An OSC presents their FIPS 140-3 validated cryptographic module during a CMMC Level 2 assessment. The module is validated at Security Level 1 under FIPS 140-3. Is this sufficient for protecting CUI?",
    "opts": [
      "No — FIPS 140-3 requires at least Security Level 2 for CUI protection",
      "No — FIPS 140-3 Security Level 1 is only for testing environments",
      "Yes — NIST SP 800-171 requires FIPS-validated cryptography but does not specify a minimum FIPS 140 security level",
      "Yes — but only if the module also holds an ISO/IEC 19790 certificate"
    ],
    "ans": 2,
    "compliment": "SECURITY LEVEL TRAP AVOIDED! 800-171 requires FIPS validation — it doesn't mandate a specific FIPS security level!",
    "praise": "NIST SP 800-171 Practice 3.13.11 requires the use of FIPS-validated cryptography. It does not specify a minimum FIPS 140 security level (1, 2, 3, or 4). A FIPS 140-3 Security Level 1 validated module satisfies the FIPS validation requirement. Higher security levels provide additional physical and logical protections but are not mandated by 800-171. An assessor who rejects a Level 1 module is adding requirements beyond what the standard specifies.",
    "burn": "800-171 says 'FIPS-validated.' It does not say 'FIPS-validated at Level 2 or higher.' Read the requirement, not your assumptions.",
    "roast": "NIST SP 800-171 requires FIPS-validated cryptography — period. It does not mandate a specific FIPS 140 security level. Security Level 1 through 4 all satisfy the requirement. Don't invent thresholds the standard doesn't specify."
  },
  {
    "cat": "exec",
    "catLabel": "ASSESSMENT EXEC",
    "diff": 3,
    "q": "During a CMMC Level 2 assessment, an OSC presents a cryptographic module with an 'active' FIPS 140-3 validation certificate from CMVP. What should the assessor verify NEXT?",
    "opts": [
      "That the module was validated by a lab located in the United States",
      "That the validated module version matches what is actually deployed in the OSC's environment and that FIPS mode is enabled in the operational configuration",
      "That the module vendor is on the DoD Approved Products List",
      "That the module supports quantum-resistant algorithms"
    ],
    "ans": 1,
    "compliment": "DEPLOYMENT VERIFICATION! A certificate means nothing if the deployed version doesn't match!",
    "praise": "Having a FIPS 140-3 certificate is necessary but not sufficient. The assessor must verify that the exact validated module version is what's actually deployed — not a different version, not an unpatched variant — and that FIPS mode is operationally enabled. Labs from any CMVP-recognized country can perform validations. There is no DoD Approved Products List for cryptographic modules. Quantum resistance is forward-looking, not a current FIPS requirement.",
    "burn": "A certificate on a shelf proves nothing about what's running in production. Verify the deployed version matches the validated version.",
    "roast": "Certificate validation is step one. Step two is confirming the deployed module version matches the certificate and that FIPS mode is enabled. Version mismatches between validated and deployed modules are one of the most common assessment findings."
  },
  {
    "cat": "reg",
    "catLabel": "REGULATORY",
    "diff": 4,
    "q": "Under FIPS 140-3, what happens when a vulnerability is discovered in a validated cryptographic module?",
    "opts": [
      "The CMVP automatically revokes the module's validation certificate",
      "The module vendor must issue a patch within 30 days or lose validation",
      "The CMVP may place the module on the Historical Validation List, and the vendor must work with a testing lab to revalidate the patched module",
      "The vulnerability has no impact on the validation status as long as the module was valid at time of testing"
    ],
    "ans": 2,
    "compliment": "HISTORICAL LIST AWARENESS! You know the CMVP vulnerability response process!",
    "praise": "When a vulnerability affects a FIPS-validated module, the CMVP can move the certificate to the Historical Validation List, indicating it is no longer recommended for new procurement. The vendor must work with a CMVP-accredited lab to test and validate the patched version as a new or updated submission. Validation is not automatically revoked, but the Historical List signals risk. The 'vulnerability doesn't matter' option ignores the ongoing assurance requirements of the program.",
    "burn": "Vulnerabilities in validated modules don't exist in a vacuum. CMVP tracks them and can move affected modules to the Historical List.",
    "roast": "CMVP maintains a Historical Validation List for modules with known vulnerabilities. Vendors must revalidate patched modules through an accredited lab. Ongoing assurance is part of the FIPS validation lifecycle."
  }
]