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
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:
- 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.
- 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.
- Add ID.RA individual-impact prompts so risk entries capture harm to people, not only business impact.
- 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.
- Add not-evaluable reason codes for privacy evidence owned outside the security team.
Sources Checked
Bounty Info
Skill Being Reviewed
Skill name:
nist-csf-assessmentSkill path:
skills/compliance/nist-csf-assessment/False Positive Analysis
Benign scenario that can be over-scored as privacy/civil-liberties coverage:
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
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
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
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
not_evaluable_privacy_owner_unavailableinstead of forcing a low cybersecurity score.not_applicablewith rationale, not silently omitted.Remediation Quality
Comparison to Other Tools
Overall Assessment
Strengths:
Needs improvement:
Priority recommendations:
Privacy / Civil Liberties Evidencesubsection covering processing purpose, notice/consent or authorization basis where applicable, retention/deletion, sharing/disclosure, individual rights, and sensitive-data impact.data_category,processing_purpose,source,sharing_path,retention_rule,deletion_rule,individual_impact, andprivacy_owner.Sources Checked
Bounty Info