How to Prove Password Compliance to Auditors: The Complete Playbook

What auditors actually ask

Password compliance questions appear in virtually every security audit, regardless of framework. But the specific questions vary by standard. Understanding exactly what auditors ask — and what they consider acceptable evidence — is the foundation of efficient audit preparation.

Across SOC 2, HIPAA, PCI-DSS, and ISO 27001, auditors ask four core questions about password controls:

1. Policy: "Show me your written password policy." — They want a dated, signed document specifying minimum length, complexity, rotation, and MFA requirements for different account types.
2. Technical enforcement: "Show me that the policy is technically enforced — not just documented." — Screenshots of Group Policy, IdP settings, or application configuration. Without this, a policy is just words.
3. Consistent application: "How do I know your high-risk credentials actually meet policy?" — This is where most organisations struggle. They have policy documents and system screenshots, but no credential-level evidence.
4. Breach awareness: "How do you detect compromised credentials?" — Evidence of breach checking, anomaly detection, or credential monitoring.

Questions 1 and 4 have well-established answers. Question 2 has a mostly adequate answer (IdP screenshots). Question 3 is the gap that compliance certificates were built to close.

Types of compliance evidence

Auditors classify evidence by reliability. From most to least reliable:

• Technical evidence (highest reliability) — system configuration exports, API responses, cryptographically signed records. Cannot be fabricated without breaking the cryptographic guarantee. PassGeni compliance certificates fall here.
• Administrative evidence (medium reliability) — written policies, meeting minutes, training records. Can be fabricated but auditors generally accept them for policies and procedures.
• Testimonial evidence (lower reliability) — interviews, verbal confirmations, self-attestation. Accepted for subjective controls but not for specific technical claims.
• Screenshots (lowest reliability) — can be fabricated, point-in-time, not machine-verifiable. Accepted out of necessity but viewed skeptically by experienced auditors.

The practical implication: compliance certificates provide higher-quality evidence than screenshots for credential-level compliance. They replace the weakest link in most audit packages.

Why screenshots and manual docs fail

Most security teams rely on screenshots and written policy documents to prove password compliance. This approach has three fundamental problems:

• Point-in-time, not credential-level: A screenshot showing "minimum 12 characters" in Active Directory proves that, at one moment, the policy was configured correctly. It does not prove any specific credential met the standard. Auditors increasingly recognise this gap.
• Not tamper-evident: Screenshots can be modified in any image editor. Experienced auditors are aware of this — it's why some request screen recordings or system exports instead of screenshots. Neither eliminates the forgery risk entirely.
• Not machine-readable: Screenshots require manual auditor review — reading the image, interpreting the settings, mapping to the standard. This creates time pressure and interpretation ambiguity. A compliance certificate is machine-readable and can be verified programmatically in seconds.

Manual policy documentation has a related problem: it proves what the organisation intended, not what actually happened at credential creation time. A policy written in January does not prove credentials created in October were compliant.

The compliance certificate approach

A PassGeni compliance certificate closes the credential-level evidence gap. It is:

• Tamper-evident — ES256-signed. Any modification to the compliance claims (inflating entropy, changing the standard, altering generation parameters) invalidates the signature immediately.
• Timestamp-anchored — the iat claim records the exact generation time. The certificate proves the credential met compliance at that specific moment, not just that a policy existed.
• Machine-readable — auditors can verify with any JOSE library in under 60 seconds. No interpretation required — the compliance_standard and standards_met claims are explicit.
• Independently verifiable — verification requires only PassGeni's public key at passgeni.ai/.well-known/jwks.json. No trust in the certificate holder is required. No call to PassGeni's servers required.
• Credential-level — each certificate is for a specific credential generation event, not a system-wide policy claim. Auditors get evidence that this specific credential was compliant, not just that the system was configured to produce compliant credentials.

Certificates supplement, not replace, written policy documents. The optimal audit package includes both: policy documents demonstrating organisational intent, and certificates demonstrating consistent execution.

SOC 2 evidence package

SOC 2 Trust Services Criteria CC6.1 covers logical access security. For password controls, a complete evidence package includes:

• Written password policy — covers minimum length (16+ chars for SOC 2), complexity, MFA, rotation, and service account requirements. Must be dated, signed by management, and show annual review. Use PassGeni's Policy Generator.
• IdP / Active Directory configuration export — screenshot or XML export of password policy settings from your identity provider. Demonstrates technical enforcement of the written policy.
• Compliance certificates for high-risk credentials — admin accounts, privileged service accounts, database credentials, CI/CD secrets. Provide the cert URL for each. Auditors independently verify. For SOC 2 Type II, having certificates from across the audit period demonstrates consistent enforcement over time.
• Access review documentation — quarterly or semi-annual review log showing who has access to which systems, with approvals. CC6.2 and CC6.3.
• Breach monitoring evidence — configuration showing credential monitoring (HIBP integration, SIEM alerts for credential stuffing). CC7.1.

HIPAA audit evidence

HIPAA audits (OCR investigations and third-party risk assessments) focus on §164.312 Technical Safeguards. For password controls, auditors assess:

• §164.312(a)(1) — Access Control: Written access control policy, evidence of unique user identification, automatic logoff configuration. Compliance certificates demonstrating credentials met HIPAA-standard generation parameters address the "unique, strong credentials" element.
• §164.312(d) — Person or Entity Authentication: Policy and evidence that authentication mechanisms are appropriate to the risk. For password-based authentication: minimum 12-character credentials with complexity, MFA for remote and privileged access, credential generation documentation.
• §164.312(b) — Audit Controls: Authentication event logs retained for 6 years. Compliance certificate records (accessible via cert URL) are persistent and dated — they contribute to the 6-year retention requirement for access control evidence.

The OCR's HIPAA audit protocol specifically asks covered entities to produce policies, procedures, and technical implementation evidence for each safeguard. Compliance certificates provide the technical implementation evidence for credential generation that is otherwise difficult to produce.

PCI-DSS v4.0 audit evidence

PCI-DSS v4.0 (mandatory since March 2024) significantly strengthened password requirements. Requirement 8.3 covers password authentication:

• Req 8.3.6 — Minimum 12 characters, 3 of 4 character types: Technical configuration evidence (IdP settings) plus compliance certificates demonstrating 12-character minimum and complexity for cardholder data environment (CDE) credentials.
• Req 8.3.9 — Password change only on evidence of compromise: Documentation showing your organisation has replaced mandatory rotation with breach-evidence-based rotation. PassGeni's breach checker integration supports this.
• Req 8.4.2 — MFA for all CDE access: IdP configuration evidence. MFA is separate from password generation evidence but auditors review both together.
• Req 8.6 — System/application account management: Service account credentials must be individually managed, not shared. Compliance certificates for each service account credential provide the individual management evidence.

QSAs (Qualified Security Assessors) conducting PCI-DSS audits are increasingly sophisticated about credential evidence. Certificates providing exact entropy_bits and generation_params align with the quantitative approach QSAs bring to their assessments.

ISO 27001 audit evidence

ISO 27001:2022 Annex A.9 (Access Control) and the associated control objectives require both documented controls and objective evidence of implementation. For password controls:

• A.9.4.3 — Password management system: Evidence of a system that enforces strong passwords, prevents reuse, and locks accounts on failure. System configuration evidence plus compliance certificates demonstrating ISO 27001-aligned generation (14+ chars, all character classes).
• A.9.2.4 — Management of secret authentication information: Evidence that credentials are provisioned securely, changed on compromise, and not shared. Compliance certificates provide the generation provenance; access logs provide the usage trail.
• Clause 9.1 — Monitoring, measurement, analysis, and evaluation: Evidence that controls are measured and effective. A portfolio of compliance certificates across the credential estate demonstrates measured, consistent enforcement.
• Clause 7.5 — Documented information: ISO 27001 requires documented evidence of control operation. Compliance certificates are documented, machine-readable, externally hosted evidence that satisfies this clause without additional manual record-keeping.

FIPS 140-3 / FedRAMP evidence

Federal audits have the most explicit requirements for credential generation evidence:

• Entropy source documentation: FIPS 140-3 requires identifying the specific validated entropy source. PassGeni certificates include entropy_source: "crypto.getRandomValues (FIPS 140-3 aligned)" — satisfying this requirement in a tamper-evident format.
• System Security Plan (SSP) references: FedRAMP-authorized systems must document credential management in their SSP. Reference PassGeni compliance certificate URLs as evidence of FIPS-aligned credential generation in the relevant control sections (IA-5, IA-5(1)).
• STIG compliance: DoD STIG assessors ask for evidence that credentials meet STIG password requirements (typically 15–20 chars, all character types). Compliance certificates with FIPS 140-3 preset satisfy these requirements and provide the documented provenance STIG assessors need.
• POA&M items: If existing credentials lack documented provenance, create a Plan of Action and Milestones item to rotate and recertify them. PassGeni certificates for rotated credentials close the POA&M item with cryptographic evidence.

Evidence retention requirements

Password compliance evidence must be retained for the duration specified by each framework:

PassGeni compliance certificates are persistently accessible via their certificate URL for the duration of their validity period. For HIPAA's 6-year requirement, archive the certificate URL (and the certificate page content) at the time of creation. The cert URL provides ongoing access; the archived snapshot provides fallback if PassGeni is unavailable.

The 2-hour audit prep playbook

For teams preparing for an upcoming audit with limited time, this sequence addresses the most common password evidence gaps in approximately 2 hours:

1. Generate written password policy (20 minutes): Use PassGeni's Policy Generator with your organisation type and applicable standards. Download, customise with your organisation name and dates, get management signature. This covers the policy evidence gap for all frameworks.
2. Identify highest-risk credentials (15 minutes): Admin accounts, service accounts, database passwords, CI/CD credentials, cloud console access. These are the credentials auditors will probe.
3. Rotate and certify high-risk credentials (45 minutes): For each high-risk credential, generate a replacement using the appropriate PassGeni compliance preset, certify it, and collect the certificate URL. Update the credential in your password manager and secrets manager. This creates the credential-level evidence that replaces missing documentation.
4. Document the certificate URLs (20 minutes): Create a simple spreadsheet: credential name | system | compliance standard | cert URL | rotation date. This is your compliance certificate registry — reference it during audit interviews.
5. Capture IdP configuration screenshots (20 minutes): Screenshot or export your identity provider's password policy settings. These supplement the certificates with system-level enforcement evidence.

Total output: written policy, IdP screenshots, compliance certificates for all high-risk credentials, and a certificate registry. This package addresses the evidence requirements for SOC 2 CC6.1, HIPAA §164.312, PCI-DSS Req 8.3, and ISO 27001 A.9 at the credential level.