CCS PDF Editor — Executive Pitch

1 The Architectural Bottom Line

What we are asking you to support Endorse CCS PDF Editor as the supported internal tool for routine PDF markup, form fill/design, local OCR, and project drafts — so staff are not forced into (a) scarce Adobe Pro seats for every click, or (b) consumer web “PDF tools” that upload files to someone else’s cloud.

Open the file. Work on the device. Save to approved storage. Keep Acrobat / e-sign for the jobs that truly need them.

Use the top links to jump; each card is one talking point. Print to PDF from the browser if you want a handout.

2 The Problem with “Everyone Needs Acrobat”

PDFs are how a behavioral-health org still ships a lot of work: packets, scans, fillable forms, markups for review. The informal tool stack drifts into three bad defaults:

Full Adobe Acrobat Pro for everyone — premium seats for tasks that are mostly “type here, stamp that, flatten, email.” Cost scales with headcount, not with complexity of the job.
Free / freemium web converters (merge, unlock, OCR, compress) — convenient until the file contains PHI or client identifiers. Then we have an accidental data-sharing incident, not a productivity win.
Edge “print to PDF” and sticky-notes — fine for reading; terrible for fillable field design, offline OCR, re-editable drafts, or controlled export passwords.

That shows up in real tickets, not theoretical ones:

Fill this form before the appointment OCR this scanned consent Mark up this policy draft Password-protect this packet Keep a draft I can reopen Don’t upload that to a random website

Risk in plain language When the org does not offer a supported offline editor, staff invent paths of least resistance. Those paths are often unlicensed, unlogged, and off-perimeter. Buying more Acrobat seats treats a licensing symptom; it does not stop the free-converter problem by itself.

3 What CCS PDF Editor Actually Does

One static application (browser pack and/or Windows WebView2 desktop shell) with libraries vendored under the app — no CDN phone-home for core editing. Same product staff already demo in IT; version 1.5.40.

Open & combine

PDF and .ccspdf projects; multi-file append; many password-protected PDFs unlock in-app.

Fill vs design

Editor + Pointer fills forms. Form workspace designs field layout (text, checkbox, radio, dropdown, signature widget).

Annotate & redact-ish

Text, images, tables, shapes; line tool thickens via corner handle for quick cover bars (visual redaction — not certified permanent redaction software).

OCR offline

English Tesseract in the client — useful on scans without a cloud OCR API or new BAA.

Save Project

.ccspdf keeps overlays + form layout re-editable, plus a short rolling edit insight log for support (not e-sign).

Save PDF

Flatten annotations; keep AcroForm fields fillable; optional client-side export password (QPDF WASM). Passwords not stored.

Deploy shapes IT already understands HTTPS static host, offline browser zip, or Windows package with desktop shortcut + .ccspdf file association. Docs pack and Windows install SOP ship with the product.

4 Market Comparison & ROI

These are order-of-magnitude list / street prices for planning conversations (USD, ~2025–2026 public commercial tiers — not CCS negotiated rates). Real Adobe/Foxit quotes move with VIP, education, and multi-year deals. The point is the shape of the spend: per-seat forever vs. fixed internal build + support.

	Adobe Acrobat Pro Business / VIP seat	Foxit / Nitro class Desktop PDF editor	Web PDF tools Smallpdf, iLovePDF, etc.	CCS PDF Editor Internal offline-first
Est. list cost	Often ~$20–$30+ / user / month (~$240–$360+ / user / year before tax & VIP) Pro features; Standard is cheaper but still per seat.	Often ~$10–$15 / user / month subscription or ~$100–$180 perpetual-style SKUs (varies)	Free tier + ads / limits; Pro often ~$5–$12 / mo or “free” with upload to vendor cloud	No per-seat license Internal build + IT support time only Host bandwidth negligible; optional WebView2 Runtime already common.
50 “power” seats / yr	~$12,000 – $18,000+	~$6,000 – $9,000+	Unclear (plus data-risk tax)	$0 seat line
Where PDF bytes go	Endpoint + Adobe cloud features if enabled	Endpoint; some cloud add-ons exist	Vendor multi-tenant cloud on most free tools	User device / org file share only
New vendor BAA for core edit?	Adobe enterprise agreements / product-specific scope	Vendor agreement if required by product mode	Often no viable BAA for free consumer tools	None for core product (self-hosted static app)
Fillable forms	Strong (industry standard)	Strong	Uneven / upload-based	Yes — fill + design AcroForm
OCR	Yes (cloud/local mix by product)	Yes (product-dependent)	Usually cloud upload	Local English OCR
Certified e-sign / identity	Via Adobe Sign / Acrobat ecosystem (extra)	Limited / partner	Not a trust framework	No — out of scope (use approved e-sign)
Central edit audit DB	Adobe cloud / admin features (paid tiers)	Limited	Vendor-side if any	No central DB; optional project /CCSProject insight + form-sign attestation digests + OneDrive versions
Best fit	Power users, heavy production PDF, legal-grade prep	Cost-conscious Acrobat alternative seats	Personal one-offs with non-sensitive files	Broad staff edit / fill / OCR / draft on CCS files

Back-of-napkin (illustrative only)

If 40 people only needed “fill + light markup + OCR” and we avoided 40 Acrobat Pro seats at ~$250/user/year:
40 × $250 ≈ $10,000 / year of list spend not required for that cohort.

We still keep a smaller Acrobat (or Foxit) pool for true power users. CCS PDF Editor is the default path, not a ban on commercial tools.

The strategic advantage Fixed internal product cost instead of linear per-seat growth for commodity PDF chores — plus a supported alternative to “upload this to a free website.” That is both a budget story and a quiet PHI story.

5 Data Posture (What Compliance Actually Hears)

Question	Straight answer
Does the app server store documents?	No. Static assets only (HTML/JS/CSS/WASM). Files open from the user’s machine or share.
Does it upload PDF content to a CCS API?	No in current release. Processing is client-side.
Can it touch PHI?	Yes, if the user opens a PHI PDF — same class of risk as Edge, Word, or Acrobat on an endpoint. Acceptable-use + approved save paths still apply.
Encryption at rest (app DB)?	N/A — no app document DB. Optional password on export is client-side; user files rely on OS / OneDrive / file-server encryption policy.
Third-party stack?	Vendored: PDF.js, pdf-lib, QPDF WASM, html2canvas, Tesseract, fonts. See product `NOTICE`.
Residual risk concentration	Endpoint handling, static-host integrity, and where users save files — not a multi-tenant PDF SaaS.

Framing that survives an audit “We reduced the incentive to use unvetted web converters, and we did not introduce a new document-holding SaaS. Endpoint and file-share controls remain the system of record for the file itself.”

6 Audit Reality — Say It Before They Ask

Leadership and auditors hear “editor” and jump to “who changed which PDF?” Be precise:

Layer	What exists
Central app audit of who edited what	Not provided — there is no document database or in-app user login.
Project trailer insight (`.ccspdf`)	On Save Project, a rolling list of ~200 high-level edits (integrity-hashed). IT can extract without the GUI via `tools\Extract Project Audit.bat`.
File-level who / when	OneDrive / share versioning and org IAM where the file is stored.
Final Save PDF	Ordinary PDF (optional user password). No project trailer.
Legal e-sign trail	Use the approved e-sign / EHR / workflow system — not this editor alone.

Important distinction The project log is support insight (“what kinds of edits were recorded”), not identity proofing. Under-claim here; over-deliver with extract demos and OneDrive version history when needed.

7 What We Are Not Claiming

Not Adobe Acrobat Pro parity — no full prepress suite, no Adobe cloud ecosystem, not every niche Acrobat feature.
Not DocuSign / Adobe Sign — image stamps and AcroForm signature widgets are not certified multi-party e-sign with identity proofing.
Not a records repository — no retention holds, no dual-control disposal, no central search of every PDF in the org.
Not “perfect OCR” — local English OCR helps; messy scans still need human eyes.
Not zero residual risk — open tabs on shared PCs, Downloads folders, and USB sticks remain human problems.
Not a ban on commercial PDF software — power users and specialty workflows still justify targeted seats.

Preference Under-claim in this room; over-deliver in an audit — not the reverse.

8 The Ask

Leadership Endorse CCS PDF Editor as the default supported tool for routine PDF edit, fill, OCR, and project drafts — and as the recommended alternative to unvetted web PDF converters for CCS work files.
Compliance / Privacy Accept the architecture story (client-side, no app document store) for inventory / SRA; keep formal e-sign and EHR as the systems of record for non-repudiation. Review the one-page Auditor FAQ.
Finance / Ops Treat Acrobat/Foxit as a smaller power-user pool, not a default for every staff member who only fills or light-marks PDFs. Revisit seat counts at the next true-up with actual usage.
IT Ship Windows package + optional HTTPS host; run Track A/D training; own file associations and the project-audit extract path for incidents; keep VERSION / inventory current.

9 Close

Give people a supported offline editor. Keep the expensive seats for the hard jobs. Keep the free web converters out of the PHI conversation. Leave a trail we can honestly describe.

Happy to walk a live demo: open a fillable PDF, OCR a scan page, Save Project vs Save PDF, optional export password, and IT extract of the project audit trailer.