Notifications
Clear all
Topic starter
08/06/2026 5:03 pm
TL;DR: Confidentiality policies often fail because organisations protect documents and data inconsistently, confuse privacy with confidentiality, and leave broad access unchecked, according to StrongDM. Least privilege, approved storage, clean desk practices, and secure disposal remain the operational baseline, not optional policy language.
NHIMG editorial — based on content published by StrongDM: Confidentiality Policy Best Practices
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams implement confidentiality controls without slowing work down?
A: Start with data classification, then align each class to simple handling rules, approved storage, and least privilege access.
Q: Why do confidentiality policies fail even when the wording looks complete?
A: They fail when the policy describes intent but does not define operational boundaries.
Q: What do teams get wrong about least privilege for confidential information?
A: They often treat least privilege as an account-management task instead of a data-handling rule.
Practitioner guidance
- Classify confidential data by handling requirement Define which information is confidential, where it may be stored, and which transfer methods are approved.
- Tighten access to confidential repositories Apply least privilege to file shares, document systems, and collaboration tools.
- Enforce secure disposal across paper and digital media Provide shredders, require secure wiping for removable media, and define when confidential material must be destroyed.
What's in the full article
StrongDM's full blog covers the operational detail this post intentionally leaves for the source:
- Practical examples of how to define confidential information for SOC 2 policy writing
- Guidance on clean desk and clean screen expectations for office environments
- Examples of approved storage and transfer rules for confidential data handling
- Termination-focused device wipe considerations for BYOD and removable media
👉 Read StrongDM's confidentiality policy best practices guide →
Confidentiality policy gaps: what IAM teams still miss in SOC 2?
Explore further
08/06/2026 7:02 pm
Least privilege is the real confidentiality control, not a policy statement. StrongDM's guidance reflects a broader truth: confidentiality collapses when access is wider than task need. That is the same governance failure seen in NHI programmes, where secrets, tokens, and service accounts are granted broad reach because convenience outruns classification. The implication is that confidential information and non-human credentials should be governed with the same entitlement discipline.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: Who is accountable when confidential information is exposed through poor handling?
A: Accountability usually sits with the data owner, the control owner, and the teams that allowed the storage or access exception to persist. In practice, SOC 2 programmes need clear ownership for classification, access approval, device enforcement, and disposal. Without named owners, confidentiality issues are discovered only after a breach or audit finding.
👉 Read our full editorial: Confidentiality policy controls still fail when access is too broad
