Repair a document-classification system when the classification model is still useful and failures are limited to configuration, policy assignment, training, or enforcement. Replace it when the model itself no longer maps to the organization’s information, users, or sharing paths. Retire it only when a documented migration preserves required access controls, records, ownership, and rollback evidence.
Start with the decision evidence
Measure the current system before choosing a path. Inventory labels, policy owners, assigned users and groups, protected repositories, supported applications, exceptions, failed access tests, unlabeled content, false positives, false negatives, and unresolved incidents. Separate label accuracy from access enforcement: a document can carry the expected label while sharing or encryption behaves differently than intended.
Microsoft describes sensitivity labels as persistent metadata that can classify content and, when configured, enforce protections such as encryption, markings, sharing defaults, and container controls. Its sensitivity-label overview also explains that multiple publishing policies and policy priority affect which labels and settings users receive. These dependencies belong in the decision record.
Repair when the model is still valid
Repair is appropriate when label names and definitions remain understandable, the necessary protection exists in the current platform, and defects are bounded. Typical repair work includes removing obsolete role assignments, correcting policy scope, simplifying priority, fixing application deployment, updating instructions, relabeling a controlled set of documents, and adding tests. Require a named owner, approved change, rollback plan, and evidence that intended access and denial both work.
Replace when the model or platform no longer fits
Replace when labels are ambiguous, classifications overlap, business processes have outgrown them, essential repositories cannot enforce the intended controls, administrators cannot explain effective access, or repeated repairs create inconsistent rules. Define the target model before choosing a tool. Map every old label to a target label, access rule, retention treatment, owner, exception path, and migration test.
Encryption and prior protection need special attention. Microsoft’s encryption guidance shows that applying a new label can have different effects on existing encryption and may require sufficient user rights. It also notes that some changed settings affect newly labeled or relabeled items rather than automatically rewriting all existing content. Test representative migrated documents instead of assuming a policy edit transformed the whole corpus.
Retire only after controlled migration
Retirement is appropriate when the information has moved to an approved replacement, the classification is no longer required, or the content has reached an authorized disposition. Do not remove a label or protection merely because adoption is low. Preserve the policy definition, migration mapping, approvals, exceptions, test results, and location of retained evidence.
NIST SP 800-53 organizes configuration changes around controlled review, approval, documentation, and verification. Apply that discipline to the retirement sequence: freeze unapproved changes, pilot with non-sensitive fixtures, migrate a bounded sample, verify access and denial, expand in stages, monitor exceptions, and keep a tested rollback. See NIST SP 800-53 Revision 5.
The decision is complete only when owners can explain the current protection state, users know which system is authoritative, every exception has a disposition, and the old system cannot silently continue creating differently classified documents.
Sources
- Learn about sensitivity labels — Microsoft
- Apply encryption using sensitivity labels — Microsoft
- Security and Privacy Controls for Information Systems and Organizations — National Institute of Standards and Technology