{"data":{"id":"SP-043","slug":"security-metrics","title":"Security Metrics and Measurement","description":"Architecture pattern for designing, implementing, and governing a security metrics programme that drives decision-making, demonstrates programme effectiveness, and closes the feedback loop across all security domains. Covers programme-level KPIs and KRIs, vulnerability management metrics (MTTR, patch coverage, SLA compliance), detection and response metrics (MTTD, MTTR, containment rate), offensive testing metrics (findings trends, remediation velocity, dwell time simulation), awareness and human risk metrics (phishing simulation rates, training completion), compliance and control effectiveness metrics, executive reporting and dashboard design, and benchmarking against industry baselines. Addresses the structural challenge that most security teams measure activity (tickets closed, scans run) rather than outcomes (risk reduced, exposure decreased), and that measurement itself introduces perverse incentives when poorly designed.","url":"https://www.opensecurityarchitecture.org/patterns/sp-043","metadata":{"release":"26.02","classification":"Governance, Risk & Compliance","status":"active","type":"pattern","datePublished":"2026-02-10","dateModified":"2026-02-10","authors":["Vitruvius"],"reviewers":[],"provenance":"Identified as a critical gap in the OSA pattern catalogue — security metrics close the feedback loop for all other patterns. Russ noted that solving metrics well could be 'another killer app' for OSA, as most security teams struggle to move beyond activity-based reporting to outcome-driven measurement. Pattern informed by NIST SP 800-55, CIS Benchmarks, and practitioner experience with the 'hamster wheel of pain' in vulnerability management."},"diagram":{"svg":"/images/sp-043-security-metrics.svg","png":""},"content":{"description":"Security metrics and measurement is the discipline of quantifying security programme effectiveness, communicating risk posture to stakeholders, and creating feedback loops that drive continuous improvement. Done well, metrics transform security from a cost centre making qualitative claims ('we are secure') into a data-driven function demonstrating measurable outcomes ('we reduced mean-time-to-remediate critical vulnerabilities from 45 days to 12 days, reducing our exposure window by 73%').\n\nMost security metrics programmes fail not from lack of data but from lack of design. Teams measure what is easy to count (scans run, tickets closed, policies published) rather than what matters (risk reduced, exposure decreased, capability improved). The result is vanity metrics that look impressive in board reports but provide no signal for decision-making. A CISO reporting '10,000 vulnerabilities patched this quarter' tells the board nothing useful — the relevant question is what percentage of critical vulnerabilities in production systems were remediated within SLA, and how that compares to last quarter and to industry peers.\n\nCharles Goodhart's observation that 'when a measure becomes a target, it ceases to be a good measure' applies directly to security. If the SOC is measured on tickets closed, analysts will close tickets faster — including by closing them without investigation. If the vulnerability management team is measured on total patches applied, they will prioritise easy patches over critical ones. If phishing simulation success is measured by click rate alone, the awareness team will send obviously fake phishing emails. Metrics must be designed to resist gaming and to measure outcomes rather than activity.\n\nThis pattern defines a metrics architecture across eight measurement domains, each with leading and lagging indicators, collection mechanisms, target-setting approaches, and reporting cadences. The architecture separates operational metrics (consumed by security teams for day-to-day management), management metrics (consumed by security leadership for programme governance), and executive metrics (consumed by the board and C-suite for risk oversight). Each layer aggregates and translates — operational detail becomes management trend becomes executive risk indicator.\n\nThe pattern also addresses the meta-problem: measuring the measurement programme itself. Are metrics being collected reliably? Are they being acted upon? Do trends correlate with actual risk reduction? Is the cost of measurement proportionate to the value of the insight?","keyControlAreas":["Programme Metrics and Governance (PM-06, PM-09, PM-14): Establish a formal security metrics programme with defined ownership (typically the CISO office or GRC function), documented methodology, and governance cadence. Define three metric tiers: operational (daily/weekly, consumed by security teams), management (monthly/quarterly, consumed by security leadership), and executive (quarterly/annual, consumed by board and C-suite). For each metric: define the measure precisely (what is counted, how, from what source), establish a baseline from current data before setting targets, set targets that are ambitious but achievable (SMART criteria), define collection frequency and automation requirements, assign an owner responsible for data quality. Implement a metrics catalogue documenting every metric with its definition, data source, collection method, owner, consumers, and review date. Review the catalogue quarterly to retire stale metrics and add new ones. PM-06 (Measures of Performance) is the primary NIST control — it requires organisations to develop, monitor, and report on security performance measures.","Vulnerability Management Metrics (RA-05, SI-02, CA-07): Measure the organisation's ability to find and fix vulnerabilities before exploitation. Key metrics: Mean Time to Remediate (MTTR) by severity — track separately for critical (target: <7 days), high (<30 days), medium (<90 days), low (<180 days); Patch Coverage Rate — percentage of systems patched within SLA (target: >95% for critical); Vulnerability Density — vulnerabilities per asset, trended monthly; Scanning Coverage — percentage of assets scanned within policy period (target: 100%); Known Exploited Vulnerability (KEV) closure rate — CISA KEV items remediated within CISA timeline; Age Distribution — histogram of open vulnerability age showing whether the backlog is growing or shrinking; Risk-Accepted Exceptions — count and age of formally risk-accepted vulnerabilities with owner and review date. Avoid: total vulnerability count (meaningless without context), raw scan output volume, counting informational findings. Data sources: vulnerability scanner (Qualys, Tenable, Rapid7), CMDB for asset inventory, ticketing system for remediation tracking.","Detection and Response Metrics (IR-04, IR-05, AU-06, SI-04): Measure the SOC's ability to detect, investigate, and contain threats. Key metrics: Mean Time to Detect (MTTD) — elapsed time from initial compromise to detection (measure from forensic timeline, not alert timestamp); Mean Time to Respond (MTTR) — elapsed time from detection to containment; Mean Time to Contain (MTTC) — elapsed time from detection to confirmed containment of the threat; Alert-to-Incident Ratio — percentage of alerts that become confirmed incidents (indicates detection quality); False Positive Rate — percentage of alerts closed as false positive (target: <70%, if higher the detection rules need tuning); Containment Rate — percentage of incidents contained before lateral movement; Coverage by MITRE ATT&CK — percentage of ATT&CK techniques with at least one detection rule (target: >60% for initial access, execution, and persistence tactics). Avoid: raw alert count (more alerts is not better), incidents closed (incentivises premature closure), uptime of SIEM (operational, not security). Data sources: SIEM/SOAR platform, EDR telemetry, incident management system, ATT&CK Navigator for coverage mapping.","Offensive Testing Metrics (CA-08, CA-02, RA-03): Measure the organisation's resilience through red team, penetration testing, and purple team exercises. Key metrics: Findings by Severity Trend — are critical/high findings decreasing over successive test cycles? Remediation Velocity — percentage of pen test findings remediated before the next test cycle; Simulated Dwell Time — how long did the red team maintain access before detection? (target: decreasing trend); Initial Access Success Rate — did the red team achieve initial access, and through what vector? Attack Path Length — number of steps from initial access to objective (crown jewels); Purple Team Coverage — percentage of MITRE ATT&CK techniques tested with confirmed detection; Mean Time to Detect Red Team — measured from red team exercise timeline, compared against real incident MTTD; Repeat Findings Rate — percentage of findings that appeared in the previous test (target: <10%, indicates remediation effectiveness). Avoid: counting total findings without severity weighting, comparing findings across different scope/methodology tests, red team metrics without corresponding blue team detection metrics. Data sources: penetration test reports, red team after-action reports, purple team exercise logs, MITRE ATT&CK Navigator.","Awareness and Human Risk Metrics (AT-02, AT-03, PM-13): Measure the organisation's human layer security through training effectiveness and behavioural indicators. Key metrics: Phishing Simulation Click Rate — percentage of employees who click simulated phishing links (target: <5%, industry average ~15-20%); Phishing Report Rate — percentage of employees who report simulated phishing to the SOC (more important than click rate — measures the positive behaviour); Time to Report — elapsed time from phishing email delivery to first employee report; Training Completion Rate — percentage of employees completing mandatory security awareness training within the required period (target: >95%); Repeat Clickers — percentage of employees who click phishing simulations more than once in 12 months (identifies individuals needing targeted intervention); Social Engineering Resistance — red team physical/vishing/pretexting success rate; Security Champion Coverage — percentage of development teams with a designated security champion. Avoid: training hours completed (activity, not effectiveness), quiz pass rates on trivial questions, click rate as the sole metric (punitive, does not measure reporting behaviour). Data sources: phishing simulation platform (KnowBe4, Proofpoint), LMS for training completion, security champion programme records.","Compliance and Control Effectiveness Metrics (CA-02, CA-05, PL-02): Measure the organisation's compliance posture and control health. Key metrics: Control Implementation Rate — percentage of required controls fully implemented versus partially or not implemented (by framework: NIST 800-53, ISO 27001, PCI DSS); Audit Finding Trend — count of audit findings by severity trended over successive audit cycles (internal and external); Plan of Action and Milestones (POA&M) — count and age of open remediation items, percentage closed within committed timeline; Framework Alignment Score — percentage of applicable controls meeting target maturity level per framework; Exception Count — number of active risk acceptances and policy exceptions with owner and review date; Control Testing Coverage — percentage of controls tested in the current assessment period; Time to Close Audit Findings — elapsed time from finding issuance to verified remediation. Avoid: compliance percentage as a single number (hides severity distribution), self-assessed scores without validation, counting policies published rather than controls implemented. Data sources: GRC platform, internal audit reports, external audit reports, OSA assessment scores.","Executive Reporting and Dashboard Design (PM-06, AU-02, PM-09): Translate operational and management metrics into executive-level risk communication. Design principles: no more than 5-7 metrics per executive dashboard (cognitive limit); use trend lines not point-in-time snapshots; show performance against target, not just current value; use traffic light (RAG) status sparingly — only where thresholds are well-defined and validated; include peer comparison where available. Standard executive metrics: Overall Risk Posture Score (composite, trended quarterly), Critical Vulnerability Exposure (count and age of unpatched critical/KEV items), Incident Impact (business hours lost, data records affected), Compliance Status by Framework (percentage meeting target maturity), Third Party Risk Summary (vendor tier distribution and assessment currency), Investment Effectiveness (security spend per employee trended, cost per incident resolved). Report cadence: board quarterly with annual deep-dive, C-suite monthly, security leadership weekly. Every metric shown to the board must have a defined 'so what' — what action would we take if this metric deteriorated?","Benchmarking and Industry Comparison (PM-06, RA-03, PM-14): Context makes metrics meaningful — knowing your MTTR is 25 days is useful, knowing the industry median is 60 days makes it powerful. Implement three benchmarking layers: internal trending (compare against your own historical performance — most reliable), peer benchmarking (compare against industry vertical — requires participation in information sharing), and maturity benchmarking (assess capability maturity against a framework like NIST CSF). Sources of benchmark data: Verizon DBIR (incident frequency and attack patterns), Ponemon/IBM Cost of a Data Breach (financial impact benchmarks), SANS Security Awareness Report (phishing click rates by industry), BitSight/SecurityScorecard (external security posture ratings), OSA Assessment Tool (pattern maturity benchmarking across industry verticals). Publish internal benchmarks within the organisation to create accountability — teams that see peer comparison data improve faster than teams that see only their own metrics. Avoid: benchmarking against unvalidated self-reported survey data, comparing metrics across organisations with different definitions, using benchmarks as absolute targets rather than directional indicators."],"assumptions":"The organisation has a security programme with multiple operational functions (vulnerability management, SOC, GRC, awareness). Data sources exist for metric collection (vulnerability scanner, SIEM, ticketing system, GRC platform). Security leadership has a reporting obligation to executive management or the board. The organisation wants to move beyond compliance-driven security toward risk-driven security with measurable outcomes.","typicalChallenges":"Goodhart's Law — metrics become targets, causing gaming behaviour (closing tickets without investigation, patching easy items first, sending obviously fake phishing emails). Vanity metrics — measuring activity (scans run, trainings delivered) rather than outcomes (risk reduced, capability improved). Green dashboard syndrome — aggregating metrics to a level where everything looks green while individual risk areas are red. Measurement without action — collecting and reporting metrics that nobody uses for decision-making. Data quality — metrics derived from incomplete asset inventories, inconsistent severity classifications, or manual data entry. Cost of collection — the measurement programme consumes resources that could be spent on actual security improvement. Translation loss — operational metrics lose fidelity as they are aggregated and simplified for executive audiences. Baseline absence — setting targets without historical data leads to arbitrary thresholds. Lagging indicator dependency — most security metrics measure past performance, not predictive risk.","indications":"Any organisation with a security programme that reports to executive management or the board. Organisations seeking to justify security investment through demonstrated outcomes. Security teams that want to move from qualitative risk statements to quantitative evidence. Organisations with multiple security tools generating data that is not aggregated into a coherent view. Any entity implementing OSA patterns that wants to measure their effectiveness over time.","contraIndications":"Very small organisations where security is a part-time function and measurement overhead exceeds the value of the insight. Organisations in the very early stages of building a security programme where the priority is implementing basic controls, not measuring them.","threatResistance":"Addresses measurement gaming through outcome-focused metric design and multi-layered measurement (activity alone is never sufficient). Reduces executive misinterpretation through structured translation from operational to executive metrics with defined 'so what' actions. Prevents green dashboard syndrome through severity-weighted metrics and drill-down requirements. Ensures measurement drives action through governance cadence requiring documented response to metric deterioration. Provides industry context through benchmarking to prevent both complacency (we are fine) and false alarm (everything is broken)."},"examples":{"Financial Services CISO Reporting":["Monthly CISO dashboard: critical KEV closure rate (98%), MTTR critical vulns (8 days vs 7-day target), SOC MTTD (4.2 hours), phishing report rate (62%), Tier 1 vendor assessment currency (100%)","Quarterly board pack: 5 headline metrics with 12-month trend lines and RAG against targets","Annual benchmarking against FS-ISAC peer data: MTTR in bottom quartile (best), phishing click rate in second quartile (improvement opportunity)","Purple team programme: 18 ATT&CK techniques tested per quarter, detection rate improved from 55% to 78% over 12 months","Risk reduction narrative: 'Critical vulnerability exposure reduced 65% year-over-year, driven by automated patching and SLA enforcement'"],"SOC Performance Management":["MTTD tracked by detection source: EDR (12 min), SIEM correlation (45 min), user report (3.2 hours), third party notification (18 hours)","Alert-to-incident ratio: 3.2% — for every 1,000 alerts, 32 become confirmed incidents requiring investigation","False positive rate by detection rule: top 10 noisiest rules identified, 4 tuned (FP rate dropped from 82% to 45%), 2 retired","MITRE ATT&CK coverage heat map: 73% detection coverage across initial access, execution, persistence; 41% across lateral movement (improvement focus area)","Analyst efficiency: mean investigation time reduced from 45 to 28 minutes through SOAR playbook automation"],"Vulnerability Management Programme":["MTTR by severity: Critical 6 days (target 7), High 22 days (target 30), Medium 68 days (target 90) — all within SLA","Patch coverage: 97.3% of production servers patched within SLA, 2.7% with approved exceptions and compensating controls","KEV closure: 100% of CISA KEV items remediated within CISA timeline over trailing 12 months","Age distribution histogram: backlog of 30+ day critical vulnerabilities reduced from 45 to 8 over 6 months","Vulnerability density: 2.3 critical/high per server (down from 4.1 twelve months ago), target 1.5 by year end"],"Executive Risk Communication":["Board-level risk scorecard: 6 metrics, each with 12-month trend, target, and industry benchmark comparison","Security investment effectiveness: cost per incident resolved decreased 34% year-over-year through automation","Regulatory readiness: PCI DSS v4 transition 94% complete, 3 remaining items on POA&M with committed dates","Third party risk summary: 12 Tier 1 vendors, all assessed within policy, 2 with open remediation items being tracked","Insurance renewal data pack: quantified metrics supporting cyber insurance underwriting and premium negotiation"],"Developing Areas":["OCSF (Open Cybersecurity Schema Framework) adoption for security data normalisation is gaining momentum as organisations struggle to aggregate metrics across heterogeneous tool stacks. Without a common schema, correlating vulnerability data from Qualys with incident data from Splunk and access data from Okta requires custom ETL pipelines per tool pair. OCSF promises vendor-neutral event normalisation, but adoption is in early stages -- fewer than 20 security vendors have published OCSF mappings, and the schema itself is still evolving with quarterly releases adding new event classes.","The shift from activity-based metrics to outcome-based metrics is well-understood conceptually but poorly implemented in practice. Most security teams can measure what they did (patches applied, alerts triaged, trainings delivered) but struggle to measure what changed as a result (risk reduced, exposure decreased, capability improved). Outcome measurement requires causal attribution that is methodologically difficult -- did MTTR improve because of SOAR automation or because the threat landscape was quieter this quarter? Emerging approaches use synthetic control methods and A/B testing adapted from product analytics, but these techniques are foreign to most security teams.","Security data lake analytics maturity is improving as cloud-native SIEM platforms (Chronicle, Sentinel, Panther) offer long-term retention and ad-hoc query capabilities that legacy SIEMs could not. The ability to run arbitrary analytical queries across years of security telemetry enables retrospective metric calculation, trend analysis, and threat hunting that periodic reporting cannot match. However, the cost of storing and querying petabytes of security data, combined with the analytics skills required to extract meaningful insights, limits this capability to large enterprises.","Risk quantification using FAIR (Factor Analysis of Information Risk) is gaining board-level interest as executives demand financial language for cyber risk. FAIR enables statements like 'our annualised loss expectancy from ransomware is $4.2M' rather than 'ransomware risk is rated High'. However, FAIR implementations require input data (threat event frequency, vulnerability prevalence, loss magnitude distributions) that most organisations cannot reliably estimate. The result is often false precision -- a quantified number that implies more confidence than the underlying data supports.","Cross-organisation benchmarking remains hampered by inconsistent metric definitions and reluctance to share data. When Organisation A reports MTTR of 15 days and Organisation B reports 25 days, the difference may reflect measurement methodology (when does the clock start?), severity classification (what counts as critical?), or scope (all assets or production only?) rather than actual performance difference. Industry initiatives (FS-ISAC benchmarking, CIS metrics) are working toward standardised definitions, but participation rates remain below the threshold needed for statistically meaningful peer comparison in most sectors."]},"references":[{"title":"NIST SP 800-55 Vol. 1 — Measurement Guide for Information Security: Identifying and Selecting Measures","url":"https://csrc.nist.gov/pubs/sp/800/55/v1/final","note":"NIST's guide to developing, selecting and prioritising information security measures, published in December 2024 in place of SP 800-55 Rev 1. Defines four types of measure: implementation, effectiveness, efficiency and impact. Volume 2 covers building a measurement programme."},{"title":"CIS Controls v8 — Measures and Metrics","url":"https://www.cisecurity.org/controls","note":"CIS Controls include specific metrics for each safeguard, organized into three Implementation Groups (IGs). Provides concrete measurement guidance for each control."},{"title":"NIST Cybersecurity Framework 2.0 — Outcome-Based Measurement","url":"https://www.nist.gov/cyberframework","note":"CSF 2.0 introduces outcome-based tiers and profiles that support maturity measurement. The Govern function (new in 2.0) includes GV.OC for organizational context measurement."},{"title":"Verizon Data Breach Investigations Report (DBIR)","url":"https://www.verizon.com/business/resources/reports/dbir/","note":"Annual report providing industry benchmark data on attack patterns, breach timelines, threat actor profiles, and incident frequency by industry vertical. Essential benchmarking source."},{"title":"MITRE ATT&CK Framework — Detection Coverage Assessment","url":"https://attack.mitre.org/","note":"ATT&CK provides the taxonomy for measuring detection coverage. ATT&CK Navigator enables visual heat maps of technique coverage for SOC metrics."},{"title":"SANS Security Awareness Report","url":"https://www.sans.org/security-awareness-training/resources/reports/","note":"Annual benchmarking data for security awareness programme metrics including phishing click rates, training completion, and programme maturity by industry."},{"title":"Ponemon Institute / IBM — Cost of a Data Breach Report","url":"https://www.ibm.com/reports/data-breach","note":"Annual report providing financial benchmarks for breach costs, MTTD and MTTR benchmarks, and cost reduction analysis by control implementation (e.g., security AI/automation, incident response testing)."},{"title":"Goodhart's Law — When a Measure Becomes a Target","url":"https://en.wikipedia.org/wiki/Goodhart%27s_law","note":"Charles Goodhart's 1975 observation that metrics used as targets lose their value as measures. Foundational concept for understanding why poorly designed security metrics create perverse incentives."},{"title":"FAIR — Factor Analysis of Information Risk","url":"https://www.fairinstitute.org/","note":"Quantitative risk analysis model providing a taxonomy for measuring and communicating information risk in financial terms. Enables risk-based metric translation for executive audiences."},{"title":"OWASP SAMM v2.0 — Software Assurance Maturity Model","url":"https://owaspsamm.org/","note":"Maturity model for software security programmes with built-in measurement criteria for each practice area. Useful for benchmarking development security metrics."}],"relatedPatterns":["SP-038","SP-031","SP-035","SP-036","SP-014","SP-018","SP-042","SP-034"],"relatedPatternNames":["Vulnerability Management and Patching","Security Monitoring and Response","Offensive Security Testing","Incident Response","Awareness and Training","Information Security Management System","Third Party Risk Management","Cyber Resilience"],"threats":[{"id":"T-43-001","name":"Goodhart's Law gaming — Security teams optimise for the metric rather than the outcome, producing impressive numbers that mask deteriorating security posture (closing tickets without investigation, patching low-risk items first, sending obviously fake phishing simulations)","mitigatedBy":["PM-06","CA-02","PM-14"]},{"id":"T-43-002","name":"Vanity metrics — Organisation measures and reports activity metrics (scans run, trainings completed, policies published) that demonstrate effort but provide no signal about actual risk reduction or programme effectiveness","mitigatedBy":["PM-06","PM-09","RA-03"]},{"id":"T-43-003","name":"Green dashboard syndrome — Metric aggregation and threshold design produces an overall 'green' status that conceals critical red areas, giving executives false confidence in security posture while significant risks remain unaddressed","mitigatedBy":["PM-06","CA-07","AU-06"]},{"id":"T-43-004","name":"Measurement without action — Organisation collects and reports comprehensive security metrics but has no governance mechanism to trigger corrective action when metrics deteriorate, reducing the programme to expensive data collection","mitigatedBy":["PM-06","PM-14","CA-05"]},{"id":"T-43-005","name":"Executive misinterpretation — Operational metrics lose fidelity during translation to executive audiences, leading to misinformed investment decisions, inappropriate risk acceptance, or disproportionate response to low-priority issues","mitigatedBy":["PM-06","PM-09","PL-02"]},{"id":"T-43-006","name":"Metric data integrity compromise — Attacker or insider manipulates the data sources feeding security metrics (vulnerability scanner results, SIEM logs, ticketing system records) to conceal real security deficiencies or ongoing compromise","mitigatedBy":["AU-06","AU-02","SI-04"]},{"id":"T-43-007","name":"Coverage blind spots — Metrics programme measures only assets, systems, or processes within its visibility, creating a false sense of comprehensive security while shadow IT, unmanaged endpoints, or unscanned networks remain invisible","mitigatedBy":["CA-07","RA-05","PM-06"]},{"id":"T-43-008","name":"Lagging indicator dependency — Organisation relies exclusively on backward-looking metrics (incidents occurred, breaches detected) rather than leading indicators (control coverage, vulnerability exposure), failing to predict and prevent future risk","mitigatedBy":["PM-06","RA-03","CA-02"]},{"id":"T-43-009","name":"Benchmark manipulation — Organisation selects favourable benchmark comparisons (smaller peers, broader industry averages, outdated datasets) to present artificially positive positioning rather than honest assessment of relative security posture","mitigatedBy":["PM-06","PM-14","RA-03"]},{"id":"T-43-010","name":"Alert fatigue from metric overload — Security teams drown in too many metrics, dashboards, and reports, losing the ability to distinguish signal from noise and ultimately ignoring metrics entirely, including those indicating genuine risk escalation","mitigatedBy":["PM-06","SI-04","AU-06"]},{"id":"T-43-011","name":"Perverse incentive from punitive measurement — Metrics used to punish individuals (naming phishing clickers, blaming teams for findings) drive behaviour underground: employees stop reporting incidents, teams stop disclosing vulnerabilities, and the organisation loses visibility into its actual risk posture","mitigatedBy":["AT-02","PM-13","IR-04"]},{"id":"T-43-012","name":"Measurement cost exceeding value — The metrics programme consumes disproportionate security resources (analyst time for manual data collection, expensive GRC tooling, reporting overhead) that would deliver more risk reduction if spent on actual security improvement","mitigatedBy":["PM-06","PM-09","PM-14"]}],"controls":[{"id":"PM-06","name":"Measures of Performance","family":"PM","emphasis":"critical"},{"id":"PM-09","name":"Risk Management Strategy","family":"PM","emphasis":"critical"},{"id":"PM-14","name":"Testing, Training, and Monitoring","family":"PM","emphasis":"critical"},{"id":"PM-13","name":"Security and Privacy Workforce","family":"PM","emphasis":"important"},{"id":"CA-02","name":"Control Assessments","family":"CA","emphasis":"critical"},{"id":"CA-05","name":"Plan of Action and Milestones","family":"CA","emphasis":"important"},{"id":"CA-07","name":"Continuous Monitoring","family":"CA","emphasis":"critical"},{"id":"CA-08","name":"Penetration Testing","family":"CA","emphasis":"important"},{"id":"RA-03","name":"Risk Assessment","family":"RA","emphasis":"important"},{"id":"RA-05","name":"Vulnerability Monitoring and Scanning","family":"RA","emphasis":"important"},{"id":"IR-04","name":"Incident Handling","family":"IR","emphasis":"important"},{"id":"IR-05","name":"Incident Monitoring","family":"IR","emphasis":"important"},{"id":"AU-02","name":"Event Logging","family":"AU","emphasis":"standard"},{"id":"AU-06","name":"Audit Record Review, Analysis, and Reporting","family":"AU","emphasis":"important"},{"id":"SI-02","name":"Flaw Remediation","family":"SI","emphasis":"important"},{"id":"SI-04","name":"System Monitoring","family":"SI","emphasis":"standard"},{"id":"AT-02","name":"Literacy Training and Awareness","family":"AT","emphasis":"important"},{"id":"AT-03","name":"Role-based Training","family":"AT","emphasis":"standard"},{"id":"PL-02","name":"System Security and Privacy Plans","family":"PL","emphasis":"standard"}],"controlFamilySummary":{"PM":4,"CA":4,"RA":2,"IR":2,"AU":2,"SI":2,"AT":2,"PL":1}}}