NetDocuments DLP (data loss prevention) is the Security Center capability that decides which actions users may take with sensitive content, while customer-managed encryption keys (CMEK) give your organization control of the keys that protect selected data. The two protect different layers. DLP governs behavior, such as sharing a restricted document with someone who has no access, and CMEK governs cryptography. Each needs its own policies, owners, testing, and audit evidence, and this guide covers how to set up both.
What are NetDocuments DLP and encryption key management?
NetDocuments DLP and encryption key management are two separate protections within the NetDocuments Security Center, one controlling user actions and the other controlling the keys that encrypt your data. DLP is a paid add-in, and the other Security Center capabilities may be licensed or bundled differently depending on your agreement.
The distinction matters because teams often treat them as one project. DLP answers the question “what can an authorized user do with this document?” CMEK answers “who controls the key that makes this data readable?” A firm can need one without the other. Most organizations need DLP well before they need CMEK, which is usually driven by a specific client, contract, or regulator. Both exist because a leak is expensive: the 2026 edition of a long-running global study puts the average cost of a data breach at $4.99 million, a record high.
How does NetDocuments DLP control what users can do?
NetDocuments DLP controls what users can do by defining which actions are allowed or prohibited for sensitive content, which guards against both honest mistakes and deliberate misuse. It focuses on stopping confidential material from being shared with people who have not been granted access.
A policy can govern actions such as downloading, printing, exporting, emailing, or sharing externally. The exact set available depends on your classifiers, policies, cabinet configuration, and product version, so confirm it in your own tenant. Every blocked action also needs a documented route for legitimate work, such as sharing through a controlled collaboration space or requesting an exception from the content owner.
Access still comes first. DLP assumes the user is already allowed into the document, so it works on top of profile-based security and Absolute access, which decide who can open content. That layer matters when a login is stolen, and an analysis of 12,195 confirmed breaches found credential abuse was the most common way attackers got in, at 22 percent.
How should you classify content before configuring DLP?
Content should be classified by sensitivity and business purpose before any DLP policy is configured, using a short, controlled taxonomy of four or five levels. Document type alone is a poor guide, since a contract can be routine in one matter and highly restricted in another.
- Public and internal. Approved marketing material and published policies allow normal collaboration. Internal operational documents allow standard internal sharing with limited external sharing.
- Confidential. Commercial contracts, budget data, and internal legal advice allow controlled sharing, with external delivery requiring approval or a secure method.
- Restricted and client-restricted. Investigations, HR records, M&A, and litigation strategy limit downloads, exports, printing, and resharing. Content governed by client terms or ethical walls follows matter-specific rules.
These tiers are a governance pattern drawn from practice. Your own taxonomy should match how your firm already talks about sensitivity, and confidential HR and legal documents usually sit in restricted cabinets that map cleanly to the top tier.
How do you design a DLP policy library in NetDocuments?
A DLP policy library in NetDocuments should map every sensitive classification to one or more policies, with permitted and prohibited actions written down for each. Most organizations need five to eight policies, and every cabinet holding restricted or regulated content should carry at least one.
- Classification-to-policy map. Keep a single record showing which classification triggers which policy and which cabinets it covers. This record is the first thing an auditor will ask for.
- Exception governance. Require written approval from both the business owner and security for any exception, and log each one in an exception register with an expiry date.
- Alert ownership. Route DLP alerts to a named information governance or security owner, and set a review window of one to two business days.
An alert nobody reads protects nothing.
What is customer-managed encryption key management in NetDocuments?
Customer-managed encryption key management (CMEK) in NetDocuments lets your organization manage the key infrastructure used to protect specified data, typically through your own cloud key management service. NetDocuments supports customer-managed key options and workspace-based encryption key management.
CMEK adds real operational responsibility. If your key administrators are unavailable or a key is mishandled, access to protected data can be affected. For that reason, enable it only where a legal, regulatory, contractual, or client requirement justifies the added complexity.
Record the specific requirement driving CMEK, along with a risk assessment and approval, before any key is created. Then validate account readiness, key ownership, permissions, and a rollback approach before moving existing data under customer-managed keys.
Who should own encryption keys in a NetDocuments CMEK program?
Encryption keys in a NetDocuments CMEK program should have a named primary owner, a technical owner, a backup owner, and an escalation contact, all recorded in a responsibility matrix. Key administration should sit apart from ordinary document administration wherever practical.
- Restricted access. Limit key management rights to a small group of approved administrators, usually two or three people, and review that access quarterly.
- Logging. Monitor access to the key management service and enable AWS CloudTrail or an equivalent to record key management calls for audit and incident response.
- Rotation and revocation. Set a documented rotation schedule based on your regulatory and contractual obligations, and write down who has authority to revoke key access and in what circumstances.
How do DLP and CMEK fit with other NetDocuments Security Center controls?
DLP and CMEK fit with other NetDocuments Security Center controls as two layers in a stack, each covering a question the others leave open. Identity comes first, access second, behavior third, and cryptography underneath all of them.
- Identity and access. Advanced authentication confirms who the user is. Workspace Security Manager and profile-based security then decide which workspaces and documents that user may reach.
- External boundaries. CollabSpaces let outside parties work on shared documents without access to the DMS, which gives DLP policies a safe alternative to point blocked users toward.
- Audit logging. Security and administrative activity logs supply the evidence for investigations and compliance reviews across every layer.
Designing these together, early in the NetDocuments implementation that also covers repository design and migration, avoids retrofitting controls onto cabinets users already depend on.
How do you test DLP and CMEK before go-live?
DLP and CMEK are tested before go-live by proving that permitted actions work, blocked actions stay blocked, and key recovery and revocation procedures run as written. A pilot usually covers 30 to 50 DLP scenarios with 15 to 25 users from legal, records, HR, finance, and administration over two to three weeks.
- DLP scenarios. Run each classification through positive and negative cases, in the web app and in ndOffice inside Word and Outlook, and confirm a blocked user can still finish the task through the approved alternative.
- Key procedures. Test recovery when a key administrator is unavailable, the response to a suspected compromise, and revocation of access where required.
- Migration exceptions. A migration account may need elevated rights, and any temporary relaxation of DLP or ethical-wall controls should be a documented exception with a restricted window, compensating controls, and immediate restoration.
Skipping role-based security testing is a common cause of chaotic go-lives, and security controls deserve the same discipline.
How should DLP and encryption key management be reviewed after rollout?
DLP and encryption key management should be reviewed on a fixed cycle, with DLP policies and classifications reviewed at least annually and key access reviewed quarterly. Material changes in threats, workflows, regulation, or client terms should trigger an extra review.
- DLP coverage. Target 100 percent of sensitive cabinets under an approved policy, 100 percent of policies with named business and security owners, and 95 to 100 percent of alerts reviewed within the agreed window.
- Key governance. Confirm logging stays enabled, every key has named primary and backup owners, and recovery or revocation tests are completed at least once a year.
- Change control. Require approval and testing for every policy edit, and target zero confirmed disclosures caused by a policy gap.
Roll out in waves, starting with the highest-risk cabinets, and expand only after reviewing blocked-action rates, exceptions, and support demand from the first group.
Conclusion
NetDocuments DLP and encryption key management work best as two distinct programs that share a classification scheme. DLP keeps authorized users from moving sensitive content where it should not go, and CMEK gives your organization control of the keys when a client or regulator requires it. Classify first, keep the policy library small, name an owner for every policy and key, and test the blocked paths as carefully as the permitted ones.
How Basla can help
Basla provides certified delivery team members for NetDocuments implementation, covering legal technology consulting, security design, content classification, NetDocuments DLP policy libraries, encryption key governance documentation, positive and negative security testing, and post-go-live support. The team works with your security, information governance, and legal operations staff to pilot controls, document exceptions, and write the review procedures your owners will follow.
Frequently asked questions
What is NetDocuments DLP?
NetDocuments DLP is a Security Center capability that defines which actions users may take with sensitive content. It helps prevent confidential material from being shared with people who have not been granted access, and it is licensed as a paid add-in.
What is the difference between DLP and CMEK in NetDocuments?
DLP and CMEK in NetDocuments protect different layers. DLP controls what users can do with content, such as sharing or downloading, and CMEK gives your organization control of the encryption keys that protect selected data.
Does every organization need customer-managed encryption keys?
Customer-managed encryption keys are needed only where a legal, regulatory, contractual, or client requirement justifies the extra operational responsibility. Most organizations implement DLP and access controls first and add CMEK when a specific obligation calls for it.
Which actions can NetDocuments data loss prevention block?
NetDocuments data loss prevention can govern actions such as downloading, printing, exporting, emailing, and external sharing. The exact actions available depend on your classifiers, policies, cabinet configuration, and product version.
Who should manage encryption keys in NetDocuments?
Encryption keys in NetDocuments should be managed by a small group of approved key administrators, with a named primary owner and backup owner for each key. Key administration should be kept separate from routine document administration where practical.
How often should DLP policies be reviewed?
DLP policies should be reviewed at least annually and after any material change in threats, workflows, regulation, or client requirements. Encryption key access should be reviewed quarterly.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*