CCS PDF Editor · Docs

# CCS PDF Editor — Auditor FAQ (one page)

Field | Value
--- | ---
Version | 1.5.40
Owner | CCS Information Technology
Approved by | CCS Information Technology
Last updated | 2026-08-15
Audience | Internal auditors, compliance, security reviewers, IT leadership

Print or PDF this page as a cover sheet. Details live in GOVERNANCE.md, ARCHITECTURE.md, and SYSTEM-PROFILE.md.

## What is it?

CCS PDF Editor is an internally developed, static web application (optional Windows WebView2 desktop shell or offline browser pack) that lets staff view, annotate, OCR, fill and design fillable PDF form fields, open many password-protected PDFs, and export PDFs—including optional client-side password protection on export. Processing is client-side. The application host serves only static assets (HTML/JS/CSS/WASM/fonts). It does not provide a multi-user document database, Entra app roles inside the SPA, webhooks, or server-side retention purge.

## Quick answers

Question | Answer
--- | ---
Who owns / supports it? | CCS Information Technology. Helpdesk: ITHelpdesk@ccsemail.org. No single employee is sole maintainer (LICENSE).
Is it SaaS / vendor cloud PDF? | No. Self-hosted (or desktop) CCS software.
Does the app server store PHI/documents? | No document store. Users open local/network files; bytes stay in browser memory until the user saves locally.
Can it process PHI? | Yes, if the user opens a PHI PDF — same class of risk as a local PDF viewer. Endpoint, file-share, and acceptable-use controls apply.
Network upload of PDF content to CCS app API? | No in the current release. Confirm during annual review if the deployment is customized.
Authentication inside the app? | None built-in. Access to the URL is via intranet / reverse-proxy / network policy.
Audit trail of who edited which PDF? | No central app audit DB (by design). Project state (schema + short rolling edit insight, last ~200 high-level changes) embeds in catalog `/CCSProject` on Save Project and Export PDF (legacy trailer still readable). Integrity-hashed; form-field signatures may include device-local attestation meta (name, time, browser/device, hash) — not identity-proofed e-sign. IT extract: `tools\Extract Project Audit.bat` / `scripts\extract-ccspdf-audit.ps1`. Who/when at file level remains OneDrive / share versioning and org IAM.
Encryption at rest (app DB / uploads)? | N/A for app storage (none). Optional password protection on PDF export is client-side QPDF (WASM); open-password for encrypted PDFs is prompted in-app. Passwords are not stored by the app. User files otherwise rely on OS / file-server encryption policy.
BAA for cloud OCR/PDF APIs? | N/A for core product (local Tesseract + vendored libs). Revisit if a future release adds SaaS processing.
Third-party code? | Yes — PDF.js, pdf-lib, QPDF WASM, html2canvas, Tesseract.js, fonts. See NOTICE.
Desktop shell? | Optional Windows WebView2 package (same UI). File associations / desktop shortcut under package `tools\`. Inventory separately if deployed.
Electronic signatures? | Insert Signature (image stamp) and Form: Signature (typed name line + local attestation + hashes in project seal). Not a certified e-sign platform with identity proofing, TSA, or multi-party non-repudiation.
Change management? | IT ticket + approval; static redeploy. See GOVERNANCE §2.
Disaster recovery? | Re-publish last known-good static package (RTO target default 72h). User documents follow normal file backups, not this app.
Primary residual risk areas? | Endpoint handling, static-host integrity, and where users save files — not a multi-user document database.
Included in enterprise SRA / inventory? | Should be — record date on SYSTEM-PROFILE.md.

## Data flow (one sentence)

User opens a file → browser processes it with vendored libraries → user saves or prints to a path they choose → no application-server document repository.

## Residual risks

1. Sensitive content in browser memory / open tabs on shared devices.
2. Saved outputs on Downloads, USB, or personal cloud if users mishandle files.
3. A compromised static host could serve malicious JavaScript.
4. No central application audit trail of who edited which PDF — only optional per-file rolling insight inside `.ccspdf` projects (not identity-bound) plus ordinary file-store versioning.
5. Offline capability means no third-party CDNs and local libraries; it is not a full offline document management system. The service worker is network-only (installability stub) and does not precache assets in this release.

## Evidence pack (where to look)

Need | Document
--- | ---
Owners, host, contacts | SYSTEM-PROFILE.md
Process, annual checklist, IR | GOVERNANCE.md
Technical design | ARCHITECTURE.md
Third-party licenses | NOTICE
Internal-use terms | LICENSE
User handling rules | USER-TRAINING.md
Windows desktop deploy | WINDOWS-INSTALL-SOP.md
Extract project audit from `.ccspdf` | `tools\Extract Project Audit.bat` (Windows package) or `scripts/extract-ccspdf-audit.ps1` (repo)
Staff how-to | HOW-TO.md (`docs/index.html`)
Browser-readable pack | marketing/ (`index.html`)

## Sign-off (optional)

Role | Name | Date
--- | --- | ---
Technical owner (IT) |  |
Reviewed for inventory / SRA |  |

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.