Skip to content
ControlVerdict
SI.L2-3.14.3CMMC Level 2Level 2

Security Alerts & Advisories

Practice statement

Monitor system security alerts and advisories and take action in response.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.14.3.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(3)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    response actions to system security alerts and advisories are identified;

    1 example covers this

  2. [b]

    system security alerts and advisories are monitored; and

    1 example covers this

  3. [c]

    actions in response to system security alerts and advisories are taken.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    SI.L2-3.14.3Security Alerts & Advisories
    Monitor system security alerts and advisories and take action in response.
    • [a]

      response actions to system security alerts and advisories are identified;
    • [b]

      system security alerts and advisories are monitored; and
    • [c]

      actions in response to system security alerts and advisories are taken.

    One advisory intake queue with a written response-action catalog and a named owner

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses all three Security Alerts & Advisories objectives: response actions are identified, advisories are monitored, and actions are taken.

    Response-action catalog [a]. Six outcomes are defined up front so triage is a classification exercise rather than an improvisation: (1) Not applicable — record the reasoning and the inventory query that proves it, then close; (2) Patch on standard SLA — hand to the flaw remediation queue at the mapped severity; (3) Emergency change — 72-hour window for anything exploited in the wild on an internet-facing asset; (4) Mitigate — configuration change, rule, or feature disable when no patch exists yet; (5) Hunt — run the advisory's indicators against historical SIEM data to check for prior exploitation; (6) Notify — inform contracts and, where required, the prime or the customer. An advisory can carry more than one outcome, and “hunt” is mandatory alongside any emergency change.

    Monitoring [b]. A named owner and a named backup subscribe to every source, and all of it lands in one shared queue rather than two individual inboxes — the single-analyst inbox is the usual failure point at this size. The queue is reviewed each business day. The KEV list is checked weekly against the software inventory as a scheduled task, so an advisory the organization never received still gets caught.

    Applicability. Every advisory is judged against the software and asset inventory, not against memory. If the inventory cannot answer whether a component is present, that is itself a finding routed to the inventory owner, because “we think we don't run that” is not an assessable answer.

    Taking action [c]. Each advisory gets a triage record within 2 business days containing the classification, the applicability evidence, the assigned outcome, and the owner. Emergency changes are approved out-of-band by the CISO or IT lead with retroactive change-board review within 5 days. Closure requires evidence: a patch ticket ID, a configuration diff, a hunt query with its result, or the not-applicable inventory query.

    Maintenance. Quarterly check that the subscribed source list still covers everything in the software inventory — new platforms arriving without their vendor feed is the common drift. Monthly report of advisory volume, classification mix, and time-to-triage. Annual tabletop exercising an emergency advisory end to end, including the notify path.

    Accepted gap. With a two-person function, simultaneous absence is a real risk. The queue is a shared mailbox with an escalation rule that pages the IT lead if an item sits untriaged for 3 days, and the annual review checks whether that rule ever fired.

    What the evidence looks like

    • Response-action catalog document with the six defined outcomes and their triggers
    • Subscription list mapped to the software inventory, with owner and backup named
    • Advisory triage records for a recent month showing classification and closure evidence
    • One completed emergency change including its hunt query and result
    • Escalation rule configuration and the quarterly source-coverage review notes

    Environment

    Two-person security function at a mid-size OSC. Advisory sources are government feeds, vendor bulletins for the platforms in use, and one industry sharing group.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.