Why does PGP create compliance and audit problems for file security?

Why PGP clashes with audit evidence and access governance

PGP is strong at confidentiality, but its control model is often file-centric rather than identity-centric. That matters because audit teams need evidence about who had access, when that access changed, and whether revocation actually took effect. When encryption state lives in local keys, exported keyrings, or informal sharing patterns, the organisation can lose a clean control record.

A second problem is that the artefact being protected can outlive the access decision that created it. A PGP-encrypted file may remain readable by anyone who still holds the key, even after employment changes, role changes, or a partner relationship ends. For compliance, the issue is not whether the file was encrypted, but whether the access path can be proven, reviewed, and removed on schedule.

That is why PGP often fits poorly into enterprise audit and compliance perspectives on identity governance and access evidence. If the control owner cannot show authoritative issuance, ownership, rotation, and revocation for the keys that protect files, the audit story becomes weak even when the cryptography itself is sound.

Where the compliance gaps usually appear

The first gap is ownership. Many PGP deployments depend on individual key pairs, ad hoc trust relationships, or manual key distribution, so the organisation cannot easily prove who is responsible for each decryption capability. The second gap is lifecycle control. Keys may be created outside standard onboarding, changed outside change management, and retired only when someone remembers to do it.

The third gap is evidence quality. Auditors usually want a repeatable chain from policy to implementation to log or record. PGP can make that chain fragile because access may be granted through shared public keys, copied private keys, old certificates, or mail client configurations that are hard to inventory. Even if the file was encrypted correctly, the surrounding control environment may still be difficult to attest.

For a control baseline, this is why SOC 2 Trust Services Criteria and similar assurance regimes tend to emphasise traceable access control, change tracking, and evidence retention rather than encryption alone. In practice, the question is whether the process can withstand review, not whether the algorithm is strong.

Why revocation is the hardest part to prove

Revocation is where PGP often becomes operationally awkward. If a key is compromised, retired, or no longer approved, the organisation must show both that revocation happened and that the revoked key can no longer be used in the active workflow. With file encryption, old copies of encrypted data may still exist, and old private keys may still be stored on endpoints, backups, or personal devices.

That creates a disconnect between the policy state and the real state. A policy may say access was removed, but unless key distribution, storage, backup handling, and recipient lists are centrally governed, the organisation may not be able to demonstrate that every effective path was closed. In audits, that gap reads as weak control assurance, not just an implementation detail.

Risk and Threat Considerations

PGP creates risk when encryption is treated as a substitute for access governance. The main exposure is not ciphertext weakness, it is inability to prove and enforce the full lifecycle of access, which can leave sensitive files effectively accessible longer than policy allows.

Failure mechanism: Keys, recipients, and revocation state are managed outside the enterprise control plane, so access changes do not flow cleanly into inventory, review, logging, or offboarding evidence.

Impact: Organisations struggle to demonstrate who could read protected files at a given time, which can weaken audit findings, increase residual access risk, and complicate incident response and legal defensibility.

Practitioner Guidance

What to verify: Confirm whether encrypted files are tied to an owned key inventory, a documented recipient list, and a revocation process that produces evidence. If you cannot trace a file back to a current approver and current key state, treat the control as incomplete.

What practitioners underestimate: The problem is usually not encryption strength, but the absence of lifecycle controls around keys and recipients. A strong cryptographic design can still fail an audit if the organisation cannot prove offboarding, rotation, or key retirement.

Decision rule: If the file must support regulated access reviews, retention rules, or incident reconstruction, prefer controls that keep access decisions inside centrally managed identity and audit systems, and use PGP only where you can still produce dependable evidence.

Practitioner takeaway: PGP is easiest to defend when it is layered onto a governed access model; it is hardest to defend when it becomes the access model.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities for SOC 2 compliance?
• Why do non-human identities create audit risk in modern environments?