How to redact information for compliance — a practical guide

2026-04-08 · 8 minute read · Compliance

If you work in healthcare, fintech, government, or any regulated industry, "redacting a screenshot" is not a vague idea — it's a procedure with documented requirements. This guide covers the four most-asked-about regimes (HIPAA, GDPR, PCI DSS, SOC 2) and what redaction actually means in each.

The shared rule across all regimes

All four require what's commonly called irreversible redaction: the original sensitive data must not be recoverable from the redacted artifact, by any means.

This rules out:

• Soft visual blur that tesseract or other OCR can recover
• Image-editor "highlight" tools that don't flatten the layer
• Cropping (the original file usually retains the cropped pixels in metadata)
• Lowering image quality / resolution
• "Hiding" by changing color to match background (still copy-pastable)

Acceptable redactions for compliance use are: solid fill (black bar) over the area, applied to a flattened image, or true text replacement at the source level.

HIPAA: protected health information (PHI)

HIPAA's Safe Harbor deidentification standard requires removing 18 specific categories of identifiers before sharing PHI in any format. The relevant ones for screen redaction:

• Names
• Geographic subdivisions smaller than a state
• Dates more specific than year (for over-89 patients)
• Phone, fax, email, SSN, medical record number, account number
• Device identifiers, IP addresses, biometric identifiers
• Photographs of the person's face

For screen recordings or screenshots of EHR systems, the practical workflow:

1. Use the EHR's "test patient" or "demo workspace" if it has one (most do)
2. If you must use real data, run RedactPro auto-detect (catches emails, IPs, phone numbers, MRN-style patterns)
3. Manually redact patient names and any face photos
4. Use the black bar mode for HIPAA-grade redaction (not blur — recoverable)
5. For final delivery, capture the redacted page as a PNG and flatten through any standard tool (Preview, Photoshop, GIMP all flatten on save)

GDPR: personal data

GDPR's definition of personal data is broader than HIPAA's. Anything that can directly or indirectly identify a person counts: name, ID, location data, online identifier, even pseudonyms in some cases.

Practical screen redaction for GDPR:

• Customer names → black bar
• Email addresses → auto-detect (RedactPro does this)
• IP addresses → auto-detect
• Cookie IDs / device fingerprints in dev tools → manual click-to-redact
• Geographic data finer than country → black bar
• "Pseudonymized" customer slugs in URLs → redact, since GDPR considers them personal data when re-identifiable

One under-discussed rule: screen recordings shared with employees count as data processing. If you record a customer's session for training, you still need a lawful basis. Redacting the customer's identifying data is the minimum.

PCI DSS: cardholder data

PCI DSS Requirement 3.3 says displayed PAN (primary account number) must be masked, with at most the first 6 and last 4 digits visible. For redacting screenshots:

• Card number → black bar over the middle digits (or entire number)
• CVV/CVC → never displayed; if it is, redact entirely
• Expiration date → not strictly PAN, but redact unless needed for context
• Cardholder name → not strictly PAN under PCI, but treat as PII under GDPR

RedactPro's auto-detect catches credit card numbers (13-19 digits with optional separators) but it does not differentiate first-6/last-4 visible from full PAN. For PCI compliance, prefer the black bar over the entire number rather than relying on a partial mask.

SOC 2: customer data and audit evidence

SOC 2 doesn't prescribe specific redaction techniques, but auditors want to see that customer data isn't leaked in your evidence packets, screen recordings, training materials, or support tickets.

The standard pre-flight for SOC 2 evidence:

1. Use a sandbox tenant if your product has one
2. If using prod data, redact customer names, emails, financial figures, internal IDs
3. Document what was redacted and why in the evidence trail (auditors care about the process, not just the result)
4. Use solid black bar — auditors flag soft blur as "potentially recoverable" in some firms

Where browser redaction is and isn't enough

RedactPro applies CSS effects and DOM overlays to a webpage as it is rendered in your browser. The underlying HTML is unchanged. This means:

• Sufficient for: Loom recordings, Zoom screen-shares, screenshots that you take after the redaction is applied. The captured pixels are flattened and the original data is gone from the artifact.
• Not sufficient for: sharing the live URL with someone, sharing the underlying HTML, sharing browser cache, anywhere the original page state would be inspectable by the recipient.

For high-stakes compliance redaction (medical records as PDFs, legal evidence packages, regulatory submissions), use proper redaction tooling on the source files (Adobe Acrobat Pro's redaction tool, Foxit's PhantomPDF, or specialized e-discovery platforms). Browser extensions are for the screen-sharing layer, not the file layer.

The compliance pre-flight checklist

1. Is this real data, or sandbox / synthetic data? (Use sandbox if available.)
2. If real, what regime applies — HIPAA, GDPR, PCI, SOC 2, or multiple?
3. List the categories of identifiers visible on the screen.
4. For each category, decide redaction style — black bar (most regimes) or appropriate alternative.
5. Apply RedactPro auto-detect (catches emails, API keys, IPs, credit cards, SSNs, UUIDs, JWTs).
6. Manually click-redact names, addresses, photos, anything auto-detect missed.
7. Capture the page (screenshot or recording).
8. Verify the captured artifact contains nothing recoverable. Watch back, OCR-test if paranoid.
9. Document your redaction procedure in your evidence trail.