CCS PDF Editor — Governance & Compliance Controls

This document captures process expectations auditors and internal reviewers ask for: who decides, how changes ship, how access works, what data risk remains, and how often we re-check.

It does not replace CCS enterprise policies (security, privacy, incident response, HR termination, records retention). It maps this application into those processes.

Related: SYSTEM-PROFILE.md, LICENSE, NOTICE, ARCHITECTURE.md.

0. Product posture

Offline-first processing reduces server-side data exposure but does not eliminate risk. Sensitive content may still appear in browser memory, screenshots, saved files, print spoolers, and synced folders. Controls must address host integrity, access to the tool, and user handling of files.

1. Ownership and knowledge transfer

Knowledge transfer requirement: At least two CCS IT staff members shall be capable of deploying/updating the static tree, verifying the app loads offline-capable assets, and performing basic troubleshooting. No single employee is the sole maintainer (LICENSE).

1.1 Responsibility matrix (summary)

2. Change management

2.1 Change types and approval

2.2 Standard change workflow

1. Request (business need or defect) in the CCS IT ticketing system.
2. Impact / risk noted (especially: any new network call, storage, or auth change).
3. Test on lab/static path when feasible.
4. Approval per table above.
5. Production deploy of static files (version note / date).
6. Docs updated if behavior or data flow changed.
7. Ticket closed with result.

Auditor ask: “Show me how changes are approved.”

Evidence: Tickets with approval trail + release notes or commit tags for the static package.

3. Disaster recovery objectives

Auditor asks: “How much app data can you lose?” → essentially only the package version if not versioned.

“How much document data?” → same as any other file staff create in Word/Adobe — not special to this app, but still real.

4. Data protection & privacy posture

4.1 What the application does with document data

4.2 What the static host holds

Only application assets (HTML, JS, CSS, fonts, WASM, icons). It should not be used as a document repository.

4.3 Residual risks

4.4 HIPAA / PHI framing (practical)

• This tool can process PHI if a user opens a PHI PDF — same as opening that PDF in a local viewer.
• The product does not create a multi-user PHI database.
• Fillable PDFs created here are still files on endpoints/shares; they are not “submitted” into an app audit trail.
• CCS should still include the tool in asset inventory / SRA as an internally supported application that may process ePHI on endpoints.
• Minimum necessary and access to source documents remain process-owner responsibilities (who is given the PDF), not something the editor can enforce.

4.5 Electronic signatures

Two related features — neither is a certified e-sign product:

Neither is, by itself:

• Identity-proofed e-signature under ESIGN/UETA product claims
• A replacement for approved e-sign vendors when policy requires them
• A multi-party approval / non-repudiation system or TSA timestamp
• Proof of which Windows/Entra user was signed in (the app has no login)

Department policy decides when an image stamp or a form name-line attestation is acceptable vs a formal e-sign system.

5. Security and operational review schedule

Enterprise risk assessment: CCS PDF Editor shall be listed in CCS application inventory and considered in scheduled security risk assessment activities under enterprise Information Security policy — even though it is “just a static app.” Record date/ticket on SYSTEM-PROFILE.md.

5.1 Annual review checklist

6. Vendor and third-party dependency review

Third-party libraries under lib/ (PDF.js, pdf-lib, html2canvas, Tesseract, fonts) shall be reviewed periodically for:

• Known security vulnerabilities and available patches
• License obligations (NOTICE)
• Continued offline operation (no accidental CDN hard-dependency for core paths)

Practice:

• Prefer vendored copies under lib/.
• After upgrades, smoke-test render, export, and OCR without third-party network access.
• Update NOTICE when components change.

Auditor ask: “How do you know embedded libraries aren’t vulnerable?”

Evidence: Annual checklist notes + version pins in tree + tickets for upgrades.

6.1 BAAs

Core product uses no cloud BA document processor. BAAs for Microsoft 365 / endpoint backup / file servers remain under those services if users save there — not invented by this app.

If a future feature calls an external OCR/PDF API: stop, add BAA review, update ARCHITECTURE data-flow, and do not enable for PHI until approved.

7. Access provisioning and deprovisioning

Auditor ask: “Who can use it?”

Answer: Staff with network access to the published URL (document that group). “Who can change it?” → IT deployers only.

8. Separation of environments

Do not use production PHI PDFs as permanent fixtures in shared test screenshots or tickets without redaction.

9. Logging and audit

If a regulated process requires “who signed what when” with non-repudiation, use an approved system of record (EHR, formal e-sign platform, departmental workflow tool with audit history, etc.), not this editor alone.

10. Incident response

Map into CCS enterprise IR. Product-specific notes:

Preserve: web server logs, deploy history, support session notes, and (if relevant) extract artifacts from the .ccspdf trailer. There is no central document audit table to export from this app.

11. Evidence pack (what to show auditors)

12. Acceptable use (summary for policy owners)

Staff may use CCS PDF Editor for authorized CCS business documents when:

1. They are permitted to view/edit that document under job role.
2. They save outputs to approved locations when the file is a record.
3. They do not use the tool to bypass systems that must retain formal audit/e-sign trails.
4. They close the session when finished on shared devices.

See USER-TRAINING.md for the short staff-facing version.

Rendered for the browser from repository markdown. Edit the .md sources, then re-run powershell -File docs/marketing/render-docs.ps1 from the repo root.