Internal audit program
Last reviewed 2026-05-18
<h2>Purpose</h2>
<p>Verify quarterly that controls claimed in this compliance program are actually operating.</p>
<h2>Cadence</h2>
<p>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.</p>
<p>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.</p>
<h2>Quarterly checklist</h2>
<p>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.</p>
<h3>Access and identity</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> List every administrator with admin-collection membership. For each: still employed? still needs admin? Google Account MFA confirmed for admin login?</li><li><input type="checkbox" disabled/> Vendor dashboards (Vercel, GCP, Firebase, Stripe, SendGrid, Sentry, GitHub, domain registrar): confirm MFA on every account; no stale accounts.</li><li><input type="checkbox" disabled/> Review the audit log for admin actions in the quarter: anything unexpected?</li><li><input type="checkbox" disabled/> Review the break-glass log (internal record): every entry justified and time-bounded?</li><li><input type="checkbox" disabled/> Review long-unused OAuth refresh tokens; purge if the user has been inactive for more than 1 year.</li></ul>
<h3>Secrets</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> Cross-check the internal secrets inventory with the live hosting-platform environment and Firebase configuration. Anything present in one but not the other?</li><li><input type="checkbox" disabled/> Any secret older than 90 days per the internal rotation log? Rotate.</li><li><input type="checkbox" disabled/> No secrets in git (periodic git-history scan for credentials).</li></ul>
<h3>Data and privacy</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> DSR (export + deletion) flow: pick a random test account; run end-to-end; verify completeness.</li><li><input type="checkbox" disabled/> Verify the scheduled retention enforcement job ran as scheduled; purged expected records.</li><li><input type="checkbox" disabled/> 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.</li><li><input type="checkbox" disabled/> Sub-processor list matches actually-configured vendors. No new vendors silently added?</li><li><input type="checkbox" disabled/> 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).</li></ul>
<h3>Application security</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> API validation audit passes: no newly introduced or unbaselined API route lacks the standard validation utility.</li><li><input type="checkbox" disabled/> Unsafe-fetch audit passes: no direct fetch of user-supplied URLs.</li><li><input type="checkbox" disabled/> Security headers present on production: HSTS, XFO, XCTO, Referrer-Policy, Permissions-Policy.</li><li><input type="checkbox" disabled/> Executable-script Content Security Policy directives do not contain <code>'unsafe-inline'</code> or <code>'unsafe-eval'</code> in production. Inline CSS remains allowed for the component library; this is a style exception, not permission for inline JavaScript.</li><li><input type="checkbox" disabled/> Dependabot backlog: no unresolved PRs older than 30 days.</li><li><input type="checkbox" disabled/> Current-checkout npm audit: no high or critical findings in the application and Firebase Functions lockfiles.</li><li><input type="checkbox" disabled/> Default-branch Dependabot alert backlog: no open high or critical alerts from the initial 2026-05-08 enablement baseline.</li><li><input type="checkbox" disabled/> Default-branch Dependabot alert SLA: no open high or critical GitHub Dependabot alerts past SLA.</li><li><input type="checkbox" disabled/> CI security workflow last run: results reviewed.</li><li><input type="checkbox" disabled/> SBOM published for the latest release.</li></ul>
<h3>Monitoring and incidents</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> Sentry alerting routes to the Security Officer; test alert fires.</li><li><input type="checkbox" disabled/> Any Sev 1/2 incidents since last review have a post-mortem filed.</li><li><input type="checkbox" disabled/> Status page: any open incidents closed out?</li><li><input type="checkbox" disabled/> Log-retention policy enforced (see the <a href="/trust/docs/logging-retention">logging & retention</a>).</li></ul>
<h3>Resilience</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> DRP last-drill date within SLA (semi-annual partial, annual full).</li><li><input type="checkbox" disabled/> Backup retention matches verified GCP settings and the <a href="/trust/docs/data-retention">data retention policy</a>.</li><li><input type="checkbox" disabled/> Bucket retention / lock policy posture matches documentation.</li></ul>
<h3>AI governance</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> AI call audit actively populating from AI calls routed through the internal AI audit handler; sample 10 recent entries.</li><li><input type="checkbox" disabled/> Per-request retention-minimization flags still set on AI calls (re-run the internal automated check).</li><li><input type="checkbox" disabled/> Bias evaluation: review the latest archived run; confirm follow-up findings are assigned and the next annual evaluation is scheduled.</li></ul>
<h3>Training and personnel</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> 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).</li><li><input type="checkbox" disabled/> Acceptable-use and confidentiality expectations acknowledged by all personnel or volunteers with approved access (see the <a href="/trust/docs/acceptable-use">acceptable use</a> and <a href="/trust/docs/access-control-policy">access control policy</a>).</li><li><input type="checkbox" disabled/> 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 <a href="/trust/docs/background-checks">background checks</a>; no additional full-time sensitive-access employee screening records are in scope today).</li><li><input type="checkbox" disabled/> Internal joiner/mover/leaver log reflects any events this quarter; for any leaver, access revoked within the 24-hour SLA documented in the <a href="/trust/docs/access-control-policy">access control policy</a> and timed against the actual revocation timestamps.</li><li><input type="checkbox" disabled/> Phishing simulation: first simulation is scheduled when at least 2 sensitive-access recipients exist.</li></ul>
<h3>Documentation and drills</h3>
<ul class="checklist"><li><input type="checkbox" disabled/> 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.</li><li><input type="checkbox" disabled/> Emergency-change register reviewed; every emergency production change has authorization timing, bypass reason, verification, rollback plan, customer impact review, and post-hoc review status.</li><li><input type="checkbox" disabled/> Public roadmap up to date at <code>/roadmap</code>.</li><li><input type="checkbox" disabled/> Walk every dated drill record; close any open action items or carry forward.</li><li><input type="checkbox" disabled/> Re-run all 5 drills locally and confirm CI green on the latest master commit.</li><li><input type="checkbox" disabled/> 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.</li></ul>
<h2>Output</h2>
<p>Each cycle produces a dated internal audit record retained in the internal evidence set, with:</p>
<ul><li>Date of audit</li><li>Auditor (usually the Security Officer)</li><li>Checklist results (pass / fail / N/A per item)</li><li>Findings + remediation items with owners and due dates</li><li>Sign-off</li></ul>
<p>Completion and sign-off are tracked in an internal compliance audit register; the admin viewer reads detailed run evidence.</p>
<p>Findings become GitHub issues tracked to closure.</p>
<h2>Escalation</h2>
<p>Any failed item of severity "high" is treated as a Sev 3 incident: triaged within 2 business days, remediation within 7.</p>
<h2>First audit</h2>
<p>Completed: Q2 2026 baseline on 2026-05-11. Subsequent quarters compare against this baseline.</p>