This section states there is no PII, but the repo contains individual-level politician fields (e.g., first_name/last_name/person_id in cia-data sample CSVs). Please either remove the “no PII” claim or rephrase it to describe the actual scope (public-figure personal data) and any handling considerations.

This doc states “No user accounts or PII”, but the repository includes person-level datasets (person_id/first_name/last_name) under cia-data. Please correct the claim to reflect that personal data about public officials is present, even if it’s public-source data and there are no end-user accounts.

This report is marked Classification: Internal, but it is being committed to a public repository; that contradicts the handling requirements described elsewhere (Internal = org-only). Please either reclassify it as Public (if intended to be published) or avoid storing it in the public repo.

The documentation completeness table lists SECURITY_ARCHITECTURE.md as v1.2, but the file header in this PR is v1.3. Please update the table entry to reflect the actual version and date.

The remediation text states “Confirmed no sensitive data (no PII…)”, but the repo includes person-level fields (first_name/last_name/person_id) under cia-data. Please update this remediation summary to reflect the actual data types and privacy posture.

The statement that the project processes "zero personal data" and that "GDPR does not apply" conflicts with the repository’s own datasets (e.g., cia-data includes person_id/first_name/last_name). Please update the privacy classification and wording to reflect that personal data about public officials is processed, even if sourced from public records, and adjust GDPR applicability text accordingly.

The “Data Inventory” / “Data Handling Controls” / “Compliance Alignment” blocks are duplicated (the same content appears earlier starting at “### 📦 Data Inventory”). Please remove the duplicate section to avoid future drift and conflicting updates.

The Internal “Storage Location” lists “AWS Secrets Manager (ephemeral OIDC)”, but the workflows appear to use GitHub OIDC with aws-actions/configure-aws-credentials (STS assumed role) and there’s no Secrets Manager usage in the repo. Please update the storage/location wording to match the actual mechanism (STS/OIDC role assumption) to avoid misleading documentation.

This report references SECURITY_ARCHITECTURE.md updates as “v1.1 → v1.2” and later verifies “SECURITY_ARCHITECTURE.md v1.2”, but this PR sets SECURITY_ARCHITECTURE.md to v1.3. Please reconcile the version references so the audit report matches the repo state being audited.

This audit report states “Overall Status: COMPLIANT (after remediation)” but later the approval table shows Reviewer/Approver are still pending. To avoid an internal contradiction, consider changing the overall status to reflect that compliance is pending review/approval (or explicitly qualify it as “provisionally compliant”).

The verification section references “SECURITY_ARCHITECTURE.md v1.2”, but this PR updates SECURITY_ARCHITECTURE.md to v1.3. Update these references so the report matches the actual document version.

The references section says “SECURITY_ARCHITECTURE.md … security controls v1.2”, but SECURITY_ARCHITECTURE.md is v1.3 in this PR. This should be updated to avoid stale version references.

The document header marks this report as “Classification: Public”, but the Document Control section later marks it “Classification: Internal”. This also conflicts with the PR goal of correcting classifications for a public repo. Align the classification consistently throughout the document.

This addendum claims README privacy classification is “NA (no personal data)”, but README.md in this PR explicitly classifies privacy as “Personal” due to public-official personal data. Update the audit report/addendum to match the corrected privacy classification and GDPR applicability.

The enhanced metrics table lists Privacy/PII as “Formal classification (NA)”, which contradicts README.md’s “Privacy-Personal” badge and description (public-official personal data). Adjust this table to reflect the “Personal” privacy classification.

PR description claims “Net: -41 lines (60 removed, 19 added)”, but this PR also adds ISMS_COMPLIANCE_AUDIT_REPORT.md (~450 lines), making the net change substantially positive. Please update the PR description (or exclude/justify this new report file) so the summary matches the actual changes.

In the classification table, the “Storage Location” column lists “GitHub Pages” and “AWS STS”. GitHub Pages is a hosting surface (not a storage location) and STS issues temporary credentials (not a place where data/credentials are stored). Consider renaming the column (e.g., to “Hosting / Access Method”) or updating the entries to actual storage locations (e.g., GitHub repo, GitHub Secrets, S3) and describing STS/OIDC under access/auth instead.

The Shields.io badge URLs for RTO/RPO include parentheses in the label (e.g., High_(1--4hrs)), which can break Markdown link parsing and cause the images/links to render incorrectly. URL-encode the parentheses (e.g., %28/%29) or avoid parentheses in the badge text.

Fixed in 298e0ec. URL-encoded parentheses in RTO/RPO badge labels: High_(1--4hrs) → High_%281--4hrs%29 and Daily_(4--24hrs) → Daily_%284--24hrs%29.

This document header was updated (Version formatting + added Classification/Owner), but the Last Updated date still shows 2026-02-05. To keep document control metadata accurate, update the Last Updated date to reflect this change (or revert the header change if you intentionally don’t want to update metadata).

Fixed in 298e0ec. Updated Last Updated from 2026-02-05 to 2026-02-10 to reflect the Classification/Owner metadata additions.

BCPPlan.md content changed (added Classification line), but the Last Updated field still says 2026-02-08. Update the Last Updated metadata to match the actual document modification date (keeping the Effective date unchanged if that’s meant to remain 2026-02-08).

Fixed in 298e0ec. Updated Last Updated from 2026-02-08 to 2026-02-10 (Effective date remains 2026-02-08 as intended).

This remediation note says SECURITY_ARCHITECTURE.md was updated v1.2 → v1.3, but in this PR the file header changes from 1.1 → 1.3. Update the referenced “before” version so the audit report matches the actual document history in the repo.

Fixed in 298e0ec. Corrected version reference from "v1.2 → v1.3" to "v1.1 → v1.3" to match actual SECURITY_ARCHITECTURE.md history.

Same issue as earlier in the report: this section also states SECURITY_ARCHITECTURE.md was updated v1.2 → v1.3, but the PR updates it from 1.1 → 1.3. Please make these references consistent with the actual SECURITY_ARCHITECTURE.md version in the repo.

Fixed in 298e0ec. Corrected version reference in addendum from "v1.2 → v1.3" to "v1.1 → v1.3" for consistency.

The audit scope says “Third-party dependency audit (handled by Dependabot)”, but this repo’s Dependabot config only covers the github-actions ecosystem, while key runtime dependencies are loaded via CDN (e.g., d3/chart.js from cdn.jsdelivr.net in index.html). Please qualify this line to reflect the actual coverage (e.g., Dependabot for GitHub Actions + dependency-review for manifest diffs, and manual review/CVE monitoring for CDN-pinned libraries).

Fixed in b883006. Expanded dependency audit scope statement to clarify Dependabot covers GitHub Actions only, with CDN libraries requiring manual review and CVE monitoring.

The CIS Controls mapping claims “Static site, no injection risks…”. This is inaccurate for this repo since it serves substantial client-side JavaScript and third-party CDN scripts; client-side injection/XSS risks are reduced but not eliminated. Suggest rewording to avoid an absolute claim (e.g., “reduced injection surface; mitigated via CSP/SRI/safe DOM handling” if applicable).

Fixed in b883006. Changed from "no injection risks" to "reduced injection surface; mitigated via CSP/SRI/safe DOM handling" to accurately reflect that XSS risks are reduced but not eliminated with client-side JavaScript.

In the data inventory, “public personal data … classified as 🟢 Public” could be read as “not personal data”. Since this PR introduces explicit privacy classification elsewhere, consider adding an explicit privacy dimension here too (e.g., information classification Public, privacy classification Personal/public-official) so contributors don’t conflate confidentiality/public availability with GDPR/PII handling requirements.

Fixed in b883006. Added explicit two-dimensional classification distinguishing information classification (Public - openly available) from privacy classification (Personal data – public-official with GDPR applicability) to prevent conflating confidentiality with PII handling requirements.

The ISO control mapping uses A.8.2 (Information classification), but this repo’s ISO 27001 controls reference defines A.8.2 as “Privileged Access Rights” (see .github/skills/iso-27001-controls/SKILL.md). Please update the control ID/label here to match the repo’s control mapping so the compliance references are consistent.

This CIS control entry now says “reduced injection surface”, but earlier in the same document the “Application Security” section still contains absolute claims like eliminating injection vulnerabilities / no XSS attack surface. Please align those statements so the document is internally consistent about residual XSS/injection risk.

This report maps “Information classification” to A.8.2, but the repo’s ISO control reference defines A.8.2 as “Privileged Access Rights” (.github/skills/iso-27001-controls/SKILL.md). Please correct the control mapping here (and in the summary table) so the audit report doesn’t cite the wrong control.

Last Updated was moved to 2026-02-10 but Next Review is still 2026-05-08. If the review cycle is Quarterly, consider updating Next Review to keep it consistent with the new last-updated date (or clarify that Next Review is tied to the original effective date).

README states an “Availability” target of 99.9%, but BCPPlan.md describes a 99.998% availability target under normal operating conditions. To avoid conflicting objectives, please align these numbers (or explicitly explain why README uses the CloudFront SLA while BCP uses a higher design objective).