Internal audit program

Purpose

Verify quarterly that controls claimed in this compliance program are actually operating.

Cadence

Run once per calendar quarter through the internal-audit console. The console runs the automated checks that can be safely run from the application, flags controls that require human review, records item-level completion notes and evidence URLs, and captures final Security Officer sign-off. Each cycle may also produce a written report retained in the internal audit evidence set.

The quarterly cycle is complemented by a documentation-review layer: five drills (business continuity, disaster recovery, joiner/mover/leaver, vendor, change) run through local compliance checks or the manual security workflow, archiving dated records in the internal audit evidence set. That keeps documentation drift visible between quarterly cycles. The quarterly audit is then the human review on top of that automated baseline.

Quarterly checklist

The admin console is the source-of-truth completion tracker. The checklist below defines the scope; items marked as human review in the console still require the Security Officer to inspect the referenced dashboard, log, or evidence and record sign-off.

Access and identity

• List every administrator with admin-collection membership. For each: still employed? still needs admin? Google Account MFA confirmed for admin login?
• Vendor dashboards (Vercel, GCP, Firebase, Stripe, SendGrid, Sentry, GitHub, domain registrar): confirm MFA on every account; no stale accounts.
• Review the audit log for admin actions in the quarter: anything unexpected?
• Review the break-glass log (internal record): every entry justified and time-bounded?
• Review long-unused OAuth refresh tokens; purge if the user has been inactive for more than 1 year.

Secrets

• Cross-check the internal secrets inventory with the live hosting-platform environment and Firebase configuration. Anything present in one but not the other?
• Any secret older than 90 days per the internal rotation log? Rotate.
• No secrets in git (periodic git-history scan for credentials).

Data and privacy

• DSR (export + deletion) flow: pick a random test account; run end-to-end; verify completeness.
• Verify the scheduled retention enforcement job ran as scheduled; purged expected records.
• Backup drill: confirm Firestore PITR and managed daily backups still match the most recent backup-review evidence; run a restore test from a managed backup; confirm the documented bucket-retention posture matches live cloud configuration.
• Sub-processor list matches actually-configured vendors. No new vendors silently added?
• Internal DPA register: every listed sub-processor has a corresponding row (also enforced continuously by an automated DPA-register coverage check and the vendor drill). For each vendor, walk the internal vendor-assessment record and back-fill any open sections (Risk assessment, Security posture, Findings).

Application security

• API validation audit passes: no newly introduced or unbaselined API route lacks the standard validation utility.
• Unsafe-fetch audit passes: no direct fetch of user-supplied URLs.
• Security headers present on production: HSTS, XFO, XCTO, Referrer-Policy, Permissions-Policy.
• Content Security Policy does not contain 'unsafe-inline' or 'unsafe-eval' in production.
• Dependabot backlog: no unresolved PRs older than 30 days.
• Current-checkout npm audit: no high or critical findings in the application and Firebase Functions lockfiles.
• Default-branch Dependabot alert backlog: no open high or critical alerts from the initial 2026-05-08 enablement baseline.
• Default-branch Dependabot alert SLA: no open high or critical GitHub Dependabot alerts past SLA.
• CI security workflow last run: results reviewed.
• SBOM published for the latest release.

Monitoring and incidents

• Sentry alerting routes to the Security Officer; test alert fires.
• Any Sev 1/2 incidents since last review have a post-mortem filed.
• Status page: any open incidents closed out?
• Log-retention policy enforced (see the logging & retention).

Resilience

• DRP last-drill date within SLA (semi-annual partial, annual full).
• Backup retention matches verified GCP settings and the data retention policy.
• Bucket retention / lock policy posture matches documentation.

AI governance

• AI call audit actively populating from AI calls routed through the internal AI audit handler; sample 10 recent entries.
• Per-request retention-minimization flags still set on AI calls (re-run the internal automated check).
• Bias evaluation: review the latest archived run; confirm follow-up findings are assigned and the next annual evaluation is scheduled.

Training and personnel

• All personnel with ongoing operational or sensitive-system access completed annual security awareness training (current baseline archived; future annual cycles signed through the internal onboarding portal).
• Acceptable-use and confidentiality expectations acknowledged by all personnel or volunteers with approved access (see the acceptable use and access control policy).
• Background checks on file for any full-time employee with production access, customer-data access, source-code access, vendor-dashboard access, or other sensitive administrative access (see the background checks; no additional full-time sensitive-access employee screening records are in scope today).
• Internal joiner/mover/leaver log reflects any events this quarter; for any leaver, access revoked within the 24-hour SLA documented in the access control policy and timed against the actual revocation timestamps.
• Phishing simulation: first simulation is scheduled when at least 2 sensitive-access recipients exist.

Documentation and drills

• All scheduled compliance documents: use the internal review console to identify any document due under its fixed calendar cadence. Annual reviews open Jan 1; quarterly reviews open Jan 1, Apr 1, Jul 1, and Oct 1; reviews within 45 days before a cycle count for that cycle.
• Emergency-change register reviewed; every emergency production change has authorization timing, bypass reason, verification, rollback plan, customer impact review, and post-hoc review status.
• Public roadmap up to date at /roadmap.
• Walk every dated drill record; close any open action items or carry forward.
• Re-run all 5 drills locally and confirm CI green on the latest master commit.
• Customer-facing SLA-language walk: read the customer-facing compliance docs and customer policy pages; flag any unconditional time-bound commitment that lacks a paired qualifier, exception path, or reference to the patch-management exception process.

Output

Each cycle produces a dated internal audit record retained in the internal evidence set, with:

• Date of audit
• Auditor (usually the Security Officer)
• Checklist results (pass / fail / N/A per item)
• Findings + remediation items with owners and due dates
• Sign-off

Completion and sign-off are tracked in an internal compliance audit register; the admin viewer reads detailed run evidence.

Findings become GitHub issues tracked to closure.

Escalation

Any failed item of severity "high" is treated as a Sev 3 incident: triaged within 2 business days, remediation within 7.

First audit

Completed: Q2 2026 baseline on 2026-05-11. Subsequent quarters compare against this baseline.