The date that mattered wasn't 2 August — the real deadline is 2 December for disclosure work

I told our leadership the date that mattered probably wasn't 2 August. Last week it hit the timelines page and social media lit up — people panicked, vendors published frenzy-checklists, and a few suppliers called asking if they should stop development altogether.

Reality check: whatever came into force on 2 August doesn’t mean everything changes overnight. For most of us the meaningful operational work is a later cutoff: the disclosure and documentation for systems already in the field are due 2 December. In plain terms: nothing exploded on 2 August, but the 2 December deadline will quietly force teams to produce evidence on things we’ve been running for months or years.

Why 2 August felt dramatic but didn’t break the plant

Dates that mark "in force" status are important legally, but they don't always map to the day your engineering team needs to rewrite the product. What usually happens:

• The regulator publishes the regulation or an amendment; the legal effect starts on a particular date.
• Transitional provisions, grandfathering clauses, and staggered compliance windows mean practical obligations arrive later.
• For existing systems, the regulator often requires disclosure/update packages by a later deadline so notified bodies/regulators can assess ongoing conformity.

So the chaos I saw after 2 August was mostly a scrambling reaction — understandable, but not the point where evidence needs to be on a shelf. The point where your QMS needs to start issuing formal disclosures, updated risk files, and traceable change records is the December date.

What "disclosure on systems already running" really means

When regulators ask for disclosure on already-deployed systems, they want a clear, reviewable package that shows:

• Device identification and status (versions, deployed configurations)
• Risk management tied to the deployed configuration
• Cybersecurity assessments and mitigations for the fielded system
• Post-market surveillance data and how that data informed decisions
• Evidence of labeling, instructions for use in the field, and any field corrections
• Traceability between claims, requirements, verification/validation, and change logs

This isn't a marketing summary. It is controlled documentation: versioned, signed-off, and auditable.

Concrete steps we implemented (or should have)

We run Class II devices; your mileage will vary, but these are the pragmatic steps we prioritized. They fit into two weeks of focused effort if you triage and own the right people.

1. Rapid inventory and triage (day 1–3)

   • Export the product/build inventory: firmware/software versions, deployed builds, supplier subcomponents.
   • Triage by clinical/risk impact: high (safety/implant), medium, low.

2. Identify the disclosure package template (day 3–5)

   • Define required artifacts: BOM, risk file excerpts, cyber assessment, PMS summary, labeling/IFU, declaration of conformity status.
   • Map who signs each artifact (RA/QA, Engineering Lead, Supplier QA).

3. Gap analysis and assignment (day 5–10)

   • For each device/version: what’s missing? (e.g., no field risk assessment, outdated V&V for a released patch)
   • Create change controls for missing items with target completion dates before 2 Dec.

4. Controlled assembly and sign-off (ongoing)

   • Use your QMS to version the package. If you have an eQMS with APIs, export manifests and attach evidence programmatically (see below).
   • Record formal approvals and keep an audit trail.

5. Communication plan

   • Tell notified bodies and internal stakeholders what you will submit and when.
   • Avoid sending half-baked packages; it wastes reviewers’ time and invites follow-up.

Automation and tooling — practical, not magical

Panic-driven manual PDFs will break you in November. Small automation wins the day:

• Inventory exports: Most eQMSes let you export controlled document lists and change-control records as CSV/JSON. Use those to build a manifest.
• Scripted packaging: A small script (Python/Node) can gather artifacts from storage, attach metadata (revision, signature), and produce a zip with a manifest.json.
• CI for disclosure bundles: Trigger the packaging script with a git tag or a QMS webhook when all required approvals are present. Run a checksum and archive to your controlled cloud with read-only retention.
• Traceability matrix automation: If requirements and tests live in the same toolchain (or are cross-referenced via IDs), generate the trace matrix programmatically instead of retyping.

We use an eQMS for controlled docs and a separate artifact store for binaries. The integration is imperfect, but exporting the doc list and using a small pipeline to assemble packages reduced a two-day manual effort to 2–3 hours.

Where teams usually trip up

• Treating this as a one-person sprint. You need RA/QA/Engineering/Supply involvement.
• Believing "we'll patch it later." Late November is a terrible time to discover half your field devices have undocumented configs.
• Not versioning the disclosure package correctly. If you update something, the package must show the revision history and approvals.

Final thought

If you were breathless after 2 August, channel that energy into a pragmatic checklist and a small automation pipeline. The December deadline is quieter but far more consequential for operational evidence. By mid-November you’ll want a dry run: build a package, hand it to RA/QA, and treat their read-through like an audit.

How have other teams automated assembly of disclosure/evidence packages for already-deployed systems — which exports did you find most reliable from your eQMS, and what minimal pipeline reduced review friction for your notified body?