Skip to content

[REVIEW] nist-csf-assessment: add privacy-risk and individual-impact evidence gates #712

@EmergentKnowledgeGroup

Description

@EmergentKnowledgeGroup

Skill Being Reviewed

Skill name: nist-csf-assessment
Skill path: skills/compliance/nist-csf-assessment/

False Positive Analysis

Benign scenario that can be over-scored as privacy/civil-liberties coverage:

assessment_scope: customer_support_saas
current_evidence:
  GV.OC-03:
    - legal_requirements_register: "security and breach-notification laws tracked"
    - contracts: "security addendum requires encryption, access control, and incident notice"
  ID.AM-07:
    - data_inventory: ["customer email", "support ticket text", "IP address"]
    - metadata: ["system owner", "storage location", "classification"]
  PR.DS-01:
    - encryption_at_rest: true
  PR.AA-05:
    - role_based_access: true
target_result:
  GV.OC-03: 3
  ID.AM-07: 3

Why this is a false positive risk:

The skill says GV.OC-03 includes privacy and civil liberties obligations, and ID.AM-07 covers data inventories and metadata. But the assessment process can still treat cybersecurity evidence such as encryption, access control, breach notification, and high-level data classification as sufficient evidence that privacy/civil-liberties obligations are understood and managed.

That can over-score a system that protects data from unauthorized access but lacks privacy-specific evidence: processing purpose, data minimization, retention basis, disclosure/sharing rules, consent or notice obligations, individual rights handling, de-identification limits, civil-liberties impact, and downstream processor/subprocessor constraints. Security controls may be strong while privacy-risk governance remains incomplete.

Coverage Gaps

Missed variant 1: privacy/civil-liberties obligations are not split from cybersecurity legal obligations

Requirement register:
- SOC 2 security controls
- breach notification timelines
- customer security addendum

Missing:
- privacy notice obligations
- lawful/authorized processing purpose
- retention/deletion rules
- individual access/correction/deletion request process
- sensitive-data or protected-class impact review

Why it should be caught:

GV.OC-03 explicitly includes privacy and civil liberties obligations, but the current skill only asks for an inventory of laws, regulations, standards, and contractual obligations. It does not require assessors to distinguish security obligations from privacy obligations, record privacy owners, or mark privacy evidence as not evaluable when only cybersecurity artifacts are available.

Missed variant 2: data inventory lacks processing-purpose and retention metadata

{
  "data_type": "support_ticket_text",
  "classification": "confidential",
  "owner": "support-platform",
  "storage_region": "us-east-1"
}

Why it should be caught:

For ID.AM-07, inventorying data type, owner, classification, and storage location is not enough for privacy/civil-liberties evidence. A CSF assessment that covers personal data should ask for designated data category, processing purpose, source, collection context, sharing/disclosure path, retention/deletion rule, legal/contractual basis where applicable, and whether the data can affect individuals if misused. Otherwise a data inventory can look mature while privacy-risk decisions remain invisible.

Missed variant 3: risk assessment is organization-impact-only and misses individual-impact harm

Risk entry:
Scenario: support-ticket database exposure
Likelihood: medium
Business impact: moderate reputational and contractual impact
Response: encrypt backups and rotate support credentials

Missing:
- individual impact from sensitive ticket contents
- potential safety, discrimination, or civil-liberties impact
- affected-individual notification/response playbook
- deletion or minimization action

Why it should be caught:

ID.RA risk assessment asks for impacts and likelihoods, but the skill frames impact mostly as organizational risk exposure. For systems processing personal or sensitive data, the assessment should require an individual-impact lens alongside business impact. That is especially important where cybersecurity events can become privacy incidents even if core service availability and business continuity remain acceptable.

Missed variant 4: breach/recovery communication omits privacy notification decision gates

Incident recovery communication:
- internal executive update
- customer status page
- regulator contact: not specified
- affected individual notice: not specified
- privacy counsel/DPO review: not specified

Why it should be caught:

RS.CO and RC.CO cover incident and recovery communication, but the output format does not require a privacy-notification decision record. For incidents involving personal data, recovery communications should include who determines notification duties, which affected populations are in scope, what facts are needed before notice, and how security recovery status is separated from privacy/regulatory notice status.

Edge Cases

  • Privacy evidence may be owned by legal, product, HR, or data-governance teams rather than the security team. The skill should allow not_evaluable_privacy_owner_unavailable instead of forcing a low cybersecurity score.
  • Some organizations may not process personal data in the assessed scope. In that case privacy fields should be marked not_applicable with rationale, not silently omitted.
  • Data inventories can contain regulated data and non-regulated telemetry in the same platform. The report should support per-data-category privacy evidence instead of one global privacy score.
  • A breach notification process can be mature while data minimization is weak; those should not collapse into one GV.OC-03 score.
  • Supplier/processor evidence matters because privacy obligations frequently flow through contracts and subprocessors, not only through internal systems.

Remediation Quality

  • Fix resolves the vulnerability
  • Fix doesn't introduce new security issues
  • Fix doesn't break functionality
  • Issues found: Add privacy/civil-liberties evidence gates to the NIST CSF assessment so security control maturity cannot be mistaken for privacy-risk maturity. The skill should add privacy-specific fields for GV.OC-03, ID.AM-07, ID.RA, RS.CO, RC.CO, and GV.SC supplier/privacy contract evidence.

Comparison to Other Tools

Tool Catches this? Notes
NIST Privacy Framework Partial Provides privacy-risk functions, categories, profiles, and implementation tiers that can complement CSF, but the current CSF skill does not operationalize that privacy evidence inside its report.
NIST CSF 2.0 Reference Tool / Implementation Examples Partial CSF 2.0 includes privacy and civil liberties language, especially GV.OC-03 and data inventory examples, but assessors still need explicit report fields to prevent security-only evidence from satisfying privacy requirements.
ISO/IEC 27701 / privacy management reviews Partial Stronger for privacy management evidence, but not integrated into this CSF assessment output.
GRC spreadsheets Partial Can track privacy obligations if customized, but commonly collapse privacy into legal/compliance notes unless purpose, retention, disclosure, and individual-rights fields are mandatory.

Overall Assessment

Strengths:

  • Strong CSF 2.0 function/category coverage, including GOVERN and supply-chain risk management.
  • Good constraints against fabricated CSF IDs and CSF 1.1/2.0 terminology drift.
  • Useful current/target profile structure and remediation roadmap.

Needs improvement:

  • Privacy and civil-liberties obligations need first-class evidence fields, not only a phrase inside GV.OC-03.
  • ID.AM-07 data inventory should include privacy metadata such as purpose, retention, disclosure/sharing, source, and individual-impact relevance.
  • Risk assessment and incident communication should separate organizational impact from individual/privacy impact.
  • Supplier and contractual evidence should distinguish cybersecurity addenda from processor/subprocessor privacy terms.

Priority recommendations:

  1. Add a Privacy / Civil Liberties Evidence subsection covering processing purpose, notice/consent or authorization basis where applicable, retention/deletion, sharing/disclosure, individual rights, and sensitive-data impact.
  2. Add per-data-category fields to ID.AM-07: data_category, processing_purpose, source, sharing_path, retention_rule, deletion_rule, individual_impact, and privacy_owner.
  3. Add ID.RA individual-impact prompts so risk entries capture harm to people, not only business impact.
  4. Add RS.CO/RC.CO privacy-notification decision fields for affected populations, regulator/individual notice triggers, privacy counsel or DPO review, and evidence needed before notice.
  5. Add not-evaluable reason codes for privacy evidence owned outside the security team.

Sources Checked

Bounty Info

  • I have read and agree to the CONTRIBUTING.md bounty terms
  • Preferred payment method: PayPal or crypto, to be provided privately after acceptance

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions