Metadata PII in Regulated Document Workflows: Sanitizing Office Files in Java

💡 Full working example available on GitHub: remove-pii-from-office-metadata-java

The Compliance Challenge: Why Manual Metadata Review Breaks at Scale

A records team ships 200 documents to an external auditor. Someone has read every page. Nobody has read the properties, and the properties are where the personal data sits: the analyst in Author, the second analyst in LastSavedBy, a department head in Manager, the subsidiary in Company, a LastPrinted timestamp from the night before the deadline, and, on anything that passed through SharePoint, an approver ID and a workflow path.

Metadata sanitization is a GroupDocs.Metadata workflow for Java that removes those identity-bearing properties from Word, Excel, and PowerPoint files and then reads the result back to report whatever survived. This article walks through the workflow as a compliance team would build it: which property groups exist, which removal rule fits each one, when a full wipe replaces the targeted passes, and why verification belongs in the same job rather than in a checklist.

The scale problem is not that removal is hard. It is that manual review does not produce a record. An auditor asking “which fields were removed from this file, and when” needs a number, and a properties dialog produces none.

Why Generic Cleanup Tools Don’t Work Here

The Windows properties dialog edits one file at a time and reaches a subset of fields. Office’s Document Inspector runs interactively, which rules it out of a nightly job. Both leave custom OOXML parts untouched, and neither writes anything a pipeline can read back.

Teams that go one level down, editing docProps/core.xml and docProps/custom.xml directly, take on a maintenance burden: an XPath expression per field, per format, revisited whenever a producing application changes a name. That work also gets the classification question wrong. Property names differ across packages, so a name list drifts out of date silently, and a rule that no longer matches looks identical to a file that was already clean.

The Solution: GroupDocs.Metadata in a Records Workflow

GroupDocs.Metadata for Java runs everything through one property search engine. A Specification object decides which properties match, removeProperties deletes each match and returns the affected count, and findProperties runs the same predicate read-only. Properties carry tags, so Tags.getPerson().getCreator() identifies author-style fields regardless of the format or package they came from.

Java has no lambda overload on removeProperties, which turns out to be an advantage here: each rule is an object, and objects are reusable. The same specification instance that clears a group can be handed to the verification scan, so the check cannot drift away from the cleanup it is supposed to test.

Implementing the Sanitization Pipeline Step by Step

Step 1 - Clear the identity group by tag

Four tag specifications joined with .or(...) cover creator, editor, manager, and company. Nothing else moves, so Title, Subject, and Keywords stay available to the records index.

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.removeProperties(
            new ContainsTagSpecification(Tags.getPerson().getCreator())
                .or(new ContainsTagSpecification(Tags.getPerson().getEditor()))
                .or(new ContainsTagSpecification(Tags.getPerson().getManager()))
                .or(new ContainsTagSpecification(Tags.getCorporate().getCompany())));
    metadata.save(outputPath);
    return affected;
}

The FileFormat.Unknown guard matters more than it looks. Without it, an unreadable file returns zero removals, which the caller cannot distinguish from a document that was clean on arrival.

Step 2 - Clear field families by name

Comment threads, revision counters, and server fields carry no tag, so they are matched by name. A small Specification subclass takes a varargs list of substrings, which lets one class serve three passes:

public class NameContainsSpec extends Specification {
    private final String[] needles;

    public NameContainsSpec(String... needles) {
        this.needles = needles;
    }

    @Override
    public boolean isSatisfiedBy(MetadataProperty candidate) {
        String name = candidate.getName();
        if (name == null) return false;
        for (String n : needles) {
            if (name.contains(n)) return true;
        }
        return false;
    }
}

The editing timeline is the group compliance teams care about most, because the number of revisions and the last print date describe how a document was produced:

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.removeProperties(new NameContainsSpec(
            "Revision", "TrackedChange", "LastPrinted", "TotalEditingTime", "EditTime"));
    metadata.save(outputPath);
    return affected;
}

The comment pass and the SharePoint pass are the same call with different substring lists: Comment, Reviewer, Reviewed for review traces, and Server, Workflow, Approver, ContentType, Template for document-server fields.

Step 3 - Wipe at the boundary

When a file leaves the organization, selectivity stops paying. One call clears every metadata package the library detects, including custom OOXML parts no targeted predicate looks for:

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.sanitize();
    metadata.save(outputPath);
    return affected;
}

Step 4 - Verify and classify what is left

The scan runs the union of every rule through findProperties and sorts the hits into two lists. Empty values and zero counters are skipped, and entries whose names begin with Comment, Revision, or Inspection are wrappers over body content rather than metadata:

String value = "";
if (p.getValue() != null && p.getValue().getRawValue() != null) {
    value = String.valueOf(p.getValue().getRawValue());
}
if (value.isEmpty() || value.equals("0") || value.equals("0.0")) continue;
String entry = p.getName() + "=" + value;
String name = p.getName() == null ? "" : p.getName();
if (name.startsWith("Comment") || name.startsWith("Revision")
        || name.startsWith("Inspection")) {
    report.contentLevelLeaks.add(entry);
} else {
    report.metadataLeaks.add(entry);
}

The split is what keeps the pass/fail signal honest. Metadata leaks must be empty. Content-level leaks stay informational, because Word comments and tracked-change authors live inside word/document.xml, and a metadata library reports them without editing them; removing those needs a content-editing library such as Aspose.Words.

When is a targeted pass better than a full sanitize?

Whenever the document is still doing work. A file circulating between reviewers needs its Title, Subject, and Keywords for search and records classification, and sanitize() takes all three. Run the identity and comment passes during collaboration, keep the descriptive fields, and save the full wipe for the moment the file crosses the boundary to an external party.

Real Workflow: An Export Job for an External Auditor

Picture the nightly job. It reads a list of document IDs, copies each file to a staging path, applies the identity pass and the server pass, calls sanitize() on anything flagged as leaving the organization, then runs the leak check against the saved copy. Each step contributes its affected count to one log line per file, and a non-empty metadata-leak list fails the job rather than logging a warning.

I once spent an afternoon on a version of this job that reported zero removals across 40 files and looked like a clean batch. The input folder held legacy .doc binaries, the format guard was returning early on every one of them, and nothing in the log distinguished “nothing to remove” from “nothing was read”. Logging the format alongside the count fixed it.

Business Impact: What This Changes

Other Scenarios Where GroupDocs.Metadata Fits

The same property engine reads as well as it removes. Comparing metadata between two versions of a document shows what an edit round changed, which is useful for ownership disputes and for spotting a file that was re-authored outside the process. Working with metadata tags rather than names is what makes both cases portable across DOCX, XLSX, PPTX, PDF, and image formats.

Getting Started with GroupDocs.Metadata for Java

Add the GroupDocs Java repository to pom.xml and depend on com.groupdocs:groupdocs-metadata. The library runs in evaluation mode without a license, which is enough to run all six operations against a sample DOCX and see the counts. Start with the identity pass, add the field-family passes as your document sources demand them, and wire the leak check in before either goes to production.

Resources

• Complete Java sample project on GitHub
• Step-by-step use case guide
• Removing metadata properties
• GroupDocs.Metadata for Java documentation
• API reference
• Free support forum