# 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](SYSTEM-PROFILE.md), [LICENSE](../LICENSE), [NOTICE](../NOTICE), [ARCHITECTURE.md](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](../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](ARCHITECTURE.md)) |
| 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](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](../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](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](ARCHITECTURE.md) §9.3 · [WINDOWS-INSTALL-SOP](WINDOWS-INSTALL-SOP.md) §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](ARCHITECTURE.md) §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](AUDITOR-FAQ.md) · [marketing/auditor-faq.html](marketing/auditor-faq.html) |
| Owners / host / contacts | [SYSTEM-PROFILE.md](SYSTEM-PROFILE.md), [README.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](../NOTICE) |
| How do users handle sensitive files? | [USER-TRAINING.md](USER-TRAINING.md) |
| Project trailer / rolling audit design | [ARCHITECTURE.md](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](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](USER-TRAINING.md) for the short staff-facing version.
