How do you write a data security policy people will follow?

A data security policy is a short document that says which data you hold, how sensitive each kind is, who may access it and what protections apply. It works when it has named owners, a few clear classes of data and rules staff can follow without a lawyer. Everything else belongs in procedures.

Why do most policies fail?

They are long, abstract and written for auditors. Staff never read them, and the rules do not match how work happens. A policy that says "all sensitive data must be encrypted" without saying which data, where and how leaves everyone guessing.

A good test: pick a random employee and ask, "May you email this customer spreadsheet to your personal address?" If the policy cannot answer that in one sentence, it needs work.

What should it contain?

1. Purpose and scope. What it covers: all employees, contractors and systems that handle company data.
2. Roles. Who owns each dataset, who approves access, who handles incidents.
3. Data classes. Three or four is plenty. For example: public, internal, confidential and restricted.
4. Rules per class. Where it may be stored, how it is shared, whether it must be encrypted, how long it is kept.
5. Access control. Least privilege, approval and regular review.
6. Handling in motion and at rest. Encryption standards, approved transfer methods, device rules.
7. Retention and disposal. How long to keep, how to delete, including backups.
8. Third parties. Due diligence and contract terms before sharing data.
9. Incidents. How to report, whom to tell and how quickly.
10. Exceptions and enforcement. How to ask for a deviation, who approves it and what happens when rules are broken.

How does classification drive everything?

Classification is the lever. NIST's guidance on mapping information types to security categories, SP 800-60, shows the idea at government scale: decide the impact of losing confidentiality, integrity or availability, and let that choose the controls. For personal data specifically, NIST SP 800-122 gives guidance on protecting the confidentiality of personally identifiable information.

Constructed example: a 40 person software company defines four classes. Public is the marketing site. Internal is the wiki. Confidential is customer contracts and source code. Restricted is production credentials and customer personal data. A one page table says restricted data must never leave production systems, needs multi factor authentication and a named approver, and is deleted within 30 days of contract end. An engineer asked to debug with a customer export can see at a glance that the answer is no, and that a masked sample is allowed.

How do controls map?

A policy states intent. Controls make it real. The catalog in NIST SP 800-53 Rev. 5 contains families such as access control, media protection, system and communications protection and incident response, which line up with the sections above. Frameworks you may be measured against, such as SOC 2 or ISO 27001, ask for a policy and evidence that you follow it. Safeguard's compliance automation can collect and map evidence to framework controls, but the policy and its enforcement stay yours.

How do you keep it alive?

• Keep the main policy to a few pages and move detail into linked procedures.
• Review at least yearly and after any significant incident.
• Tie it to tools: default encryption, access reviews in the identity system, automated retention.
• Train new staff in the first week, using real examples.
• Track exceptions. A growing pile means a rule does not fit.

How to check or apply this

1. Inventory your main data types and where each lives.
2. Define three or four classes and assign each type.
3. Write one table with the rules per class and put it first in the document.
4. Name an owner for each dataset.
5. Check that tools enforce at least the top rules, for example storage encryption and access approval.
6. Run a quick quiz with five realistic scenarios and see if staff answer correctly from the policy.
7. Schedule the next review and put it in a calendar.

Quick check

Sources

• NIST SP 800-60 Vol. 1 Rev. 1, Guide for Mapping Types of Information and Systems to Security Categories
• NIST SP 800-122, Guide to Protecting the Confidentiality of PII
• NIST SP 800-53 Rev. 5, Security and Privacy Controls

Last reviewed: 18 October 2026.