CCS PDF Editor · Docs

# CCS PDF Editor — Governance & Compliance Controls

Field | Value
--- | ---
Version | 1.5.40
Owner | CCS Information Technology
Approved by | CCS Information Technology
Last updated | 2026-08-15
Review frequency | Annual (or after significant architectural or regulatory change)
Next review | 2027-08-05

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

Characteristic | This application
--- | ---
Application database of documents | None
Where document bytes live while editing | Browser memory (+ optional desktop shell)
Where documents land after save | User-chosen path (endpoint, share, downloads)
Built-in app authentication / audit DB | None (URL access controlled at the network edge)
Server-side retention / purge engine | None
Disaster recovery for the application package | Re-deploy static files
Disaster recovery for user documents | Normal file / endpoint backups

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

Role | Responsibility
--- | ---
Business owner | Whether staff may use the tool for a given document class; operational expectations
Technical owner / custodian | CCS IT — host the static app, patch host, release updates, dependency hygiene
Support | IT Helpdesk (ITHelpdesk@ccsemail.org) as entry point
End users | Handle open/saved documents under CCS security & records rules

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)

Activity | Responsible
--- | ---
Application support / re-deploy | CCS IT
Security review of host + package | CCS IT
Who may open the internal URL | CCS IT / network access policy
Document content decisions | Department / document owner
Where final PDFs are stored | User + department file standards
Platform code change approval | CCS IT
Third-party lib upgrades | CCS IT / developers

## 2. Change management

### 2.1 Change types and approval

Change type | Examples | Approval
--- | --- | ---
Content / UX copy | Help text, labels | CCS IT (or designated maintainer)
Feature behavior | Export quality, OCR options, tools | CCS IT
Security-sensitive | Service worker caching strategy, external URL introduction, CSP, host auth | CCS IT (security review as needed)
Dependency upgrade | pdf.js, pdf-lib, Tesseract, html2canvas | CCS IT (+ smoke test)
Major architecture | Cloud processing, server-side upload API, auth inside app | CCS IT change review + update this pack
Emergency fix | Broken export, XSS, supply-chain issue | CCS IT on-call; document after-action in ticket

### 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

Objective | Default target | Meaning
--- | --- | ---
RTO (app available again) | 72 hours | Time to re-publish static app on an approved host
RPO (app code) | Last approved release | No multi-user document store to lose inside the app
User document RPO | Per file-backup policy | OneDrive / file server / endpoint backup — not this product

Item | Practice
--- | ---
App backup | Keep release zips / git tags of the tree that was deployed
Restore test | At least annually: re-deploy to lab host, open sample PDF, export
Document recovery | Train users that Save Project / Save PDF outputs must land on approved storage if the work is a record

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

Stage | Where data lives | Sent to CCS app server?
--- | --- | ---
Open file | Browser memory (`ArrayBuffer`, canvas, DOM) | No
Edit overlays | DOM + in-memory structures | No
OCR | Local WASM / worker + trained data under `lib/` | No
Save project / PDF | User-chosen disk path or browser download folder | No
Optional PDF password on export | Applied only in the browser before download/write; password not stored by the app | No
Print | Browser / OS print pipeline | No (local devices / org print servers per policy)

### 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

Risk | Mitigation
--- | ---
Sensitive PDF open on shared/unlocked workstation | Screen lock, clean desk, user training
Browser crash / memory remnants | Close tab when done; avoid shared kiosk profiles for PHI work
Saved file on personal USB / personal cloud | Acceptable-use + DLP policies already used for Office docs
Compromised static host injects malicious JS | HTTPS, host hardening, least privilege deploys, integrity monitoring as available
Stale browser cache after deploy | Network-only SW + `config.js` `?v=` cache-bust; hard-refresh if needed (ARCHITECTURE)
Signature images or form signature widgets misused as “legal e-sign” | Training: neither is a certified e-signature platform with identity proofing
Screenshots / remote support tools | Existing CCS remote-support and privacy rules

### 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:

Feature | Behavior
--- | ---
Insert Signature (Editor) | Stamps a user-provided image onto the page; flattened on Export PDF
Form: Signature field (Form design / Editor fill) | Name line for PDF readers (text export, not browser `FT:Sig`). On fill, user confirms a fixed attestation text; app stores signed name, timestamp, basic browser/device meta, and digests (`attestationHash`, document `originHash`) in project schema → layered schemaHash seal. Compact caption under the field; hover popover shows full hashes with Copy.

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

Review | Frequency | Owner
--- | --- | ---
Security / architecture review | Annually | CCS IT
Dependency / NOTICE review | Annually (and after major upgrades) | CCS IT / developers
Access path to host URL | Annually (who can reach the site) | CCS IT / network
Re-deploy / smoke test | Annually | CCS IT
Review after material change | After significant change (especially any new outbound network call) | CCS IT

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

# | Item | Done
--- | --- | ---
1 | App re-deploy / lab smoke test (open, OCR sample, save project, save PDF) | ☐
2 | Confirm no unexpected outbound document APIs in shipped JS | ☐
3 | Dependency versions / known CVEs spot-checked; NOTICE still accurate | ☐
4 | Host TLS + access restriction still correct | ☐
5 | Documentation pack reviewed (this file, SYSTEM-PROFILE, USER-TRAINING) | ☐
6 | Support contacts / ownership current | ☐
7 | Included in enterprise app inventory / SRA cycle | ☐
8 | User training / acceptable-use reminders still accurate | ☐
9 | Optional desktop (Tauri) build inventory updated if in use | ☐

Field | Value
--- | ---
Review year | _[YYYY]_
Completed by | _[name]_
Date | _[YYYY-MM-DD]_
Ticket / evidence | _[link or number]_
Findings / follow-ups | _[or “None”]_

## 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

Control | How it works for this app
--- | ---
Authentication | Not inside the SPA. Use intranet access control (VPN, reverse proxy auth, IP allow lists, etc.) as CCS standard for internal tools.
Authorization | Anyone who can load the URL can use the editor on documents they can open from their device.
Joiner | No app role to assign; grant network path if the tool is restricted.
Mover / leaver | Disable network/VPN/SSO access per normal CCS offboarding; no app DB user row.
Privileged | Deploy rights to the static host are admin-level — limit to CCS IT.

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

Environment | Purpose | Data rules
--- | --- | ---
Lab / dev | Feature test | Prefer synthetic PDFs; avoid real PHI when possible
Production OWA | Staff use | Real documents allowed under policy; still client-side only

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

## 9. Logging and audit

Layer | What exists
--- | ---
Central application audit of who edited which PDF | Not provided (by design — no server document store)
Project change log (`.ccspdf` / Export PDF) | Optional insight only: last ~200 high-level edits in embedded `/CCSProject` schema (`audit[]`), integrity-hashed, size-capped (~128 KB gzip). Not identity proofing; values truncated. See ARCHITECTURE.md §9.2
IT extraction of trailer audit | `tools\Extract Project Audit.bat` (Windows package) or `scripts\extract-ccspdf-audit.ps1` — gunzip/verify, not QPDF password removal. ARCHITECTURE §9.3 · WINDOWS-INSTALL-SOP §8
Web server access logs | May show who loaded `index.html` / assets (IP/user if reverse proxy auth) — retain per host log policy
Browser console | Local only; not a compliance log
File-level who/when | OneDrive / network share versioning and org IAM where the user saved the file
Final Save PDF (`.pdf`) | Ordinary PDF (optional user-chosen export password); no project trailer / rolling 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:

Scenario | Immediate actions
--- | ---
Malicious static JS on host | Take site offline / restore known-good release; treat as host compromise
User emailed PHI PDF after editing | Standard data-handling incident path (not unique to this app)
Dependency zero-day in pdf.js / etc. | Risk assess; patch/vend new build; temporary disable URL if severe
Lost laptop with open PHI PDF | Endpoint incident + full-disk encryption assumptions per CCS policy
Contested edits to a project file | Work from a copy; run project audit extract (ARCHITECTURE §9.3); pair with file-share version history

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)

Ask | Evidence
--- | ---
What is this system? (cover sheet) | AUDITOR-FAQ.md · marketing/auditor-faq.html
Owners / host / contacts | SYSTEM-PROFILE.md, README.md
Who owns/supports it? | SYSTEM-PROFILE contacts + LICENSE
Does it store PHI on a server? | ARCHITECTURE data-flow + this §4
How do changes ship? | This §2 + tickets
Third-party software? | NOTICE
How do users handle sensitive files? | USER-TRAINING.md
Project trailer / rolling audit design | ARCHITECTURE.md §9.2–9.3
Extract insight from a `.ccspdf` | `tools\Extract Project Audit.bat` or `scripts\extract-ccspdf-audit.ps1`
Annual review? | §5.1 completed checklist
DR? | Re-deploy smoke test record on SYSTEM-PROFILE
Full pack in a browser | marketing/index.html

## 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.