CRA Reporting Copilot / Documentation

Documentation

This product is a compliance-support tool, not legal advice. It does not determine, submit, or guarantee compliance with CRA (Regulation (EU) 2024/2847) reporting obligations. You (the manufacturer) remain responsible for all reporting decisions, submissions, and deadlines. Verify all outputs and consult a qualified professional.

1. Overview

CRA Reporting Copilot has three parts. Readiness Check (free) tells you where you stand. Reporting & Notifications (paid) turns a ticket into the Article 14 draft set with staged deadline tracking. Vulnerability Register & Drills (paid) keeps a standing register, matches it against a bundled KEV snapshot, lets you rehearse in a drill, and archives past reports. Everything runs inside your Atlassian tenant; nothing is filed on your behalf.

2. Readiness Check (free)

  1. Open the app from your Jira or Jira Service Management project.
  2. Inventory your in-scope products. Add the products with digital elements you place on the EU market. Include legacy products already on the market — the reporting duty reaches them. The inventory questions guide scope; where scope is genuinely uncertain, the item is flagged for your confirmation rather than decided for you.
  3. Run the eligibility check. The app scans the Jira/JSM issues you point it at and surfaces incident and vulnerability types that could be reportable.
  4. Preview deadlines. For a case that could be reportable, the app previews the staged deadlines that would apply, including the correct final-report start point for the vulnerability vs. severe-incident path.

The Readiness Check does not generate submittable drafts and does not export — it is the free way to see your exposure before moving to a paid plan.

3. Reporting & Notifications (paid)

  1. Open a ticket representing the incident or vulnerability.
  2. Set the start events. Enter the awareness time (and, for the vulnerability path, when a corrective/mitigating measure becomes available; for the incident path, when the 72-hour notification is submitted). The app uses these to start each clock. Awareness time is yours to confirm — the app does not infer it.
  3. Generate the draft set: 24-hour early warning, 72-hour notification, final report, affected-user notice, and — if a third-party component is involved — upstream-component-maker notice. Placeholders are filled from the ticket where possible.
  4. Review and edit. Drafts are drafts. Fields dependent on official guidance (e.g., anything keyed to "becomes aware") and any not-yet-confirmed submission-format fields are flagged for you to complete or confirm.
  5. Watch the countdowns. Each stage counts down from its correct start point, with alerts as deadlines approach. The vulnerability final report tracks to 14 days after a fix is available; the severe-incident final report tracks to one month after the 72-hour notification is submitted.
  6. Export and submit. Export as PDF or JSON and submit through the current official channel yourself. The app records the action in the append-only log and keeps the draft in the archive.

4. Vulnerability Register & Drills (paid)

Register
Maintain a list of your products and components. The app matches it against the bundled KEV snapshot and surfaces items that could be reportable, so you see exposure in normal times, not only during an incident. The snapshot date is shown on the register.
Drill mode
Inject a mock incident and run the full flow — draft generation, staged deadline tracking — as practice. Nothing is submitted, and every draft is stamped with a training watermark so it can't be confused with a real filing. Use it to rehearse before a real event.
Archive
Submitted and past drafts are searchable and reusable, so a later report can build on an earlier one.

5. Understanding the deadlines (reference)

PathEarly warningNotificationFinal report — start point
Actively exploited vulnerabilitywithin 24 hourswithin 72 hourswithin 14 days after a corrective or mitigating measure is available
Severe incidentwithin 24 hourswithin 72 hourswithin one month after the 72-hour notification is submitted

The final-report start points differ by path — this is the distinction the app keeps for you. In addition to reporting to the authorities, Article 14 requires notifying affected users, and where a third-party component is involved, the upstream component maker. The app drafts both notices. Interpretation of when you "become aware" is left to you and confirmed at entry.

6. Data, storage, and audit

The app runs on Atlassian-hosted compute and storage with no external egress. Your issue data, register, drafts, and logs stay in your tenant. There is no external LLM or live feed. Every reporting action is recorded in an append-only log. The KEV data is a bundled snapshot refreshed through app updates, with its date shown in the app.

7. Troubleshooting

The app can't see my issues.
Confirm the app was granted read access to Jira work data at install, and that you are pointing it at a project you can view. It requests no write access.
A draft field is blank or flagged.
Fields that depend on official guidance or on an as-yet-unconfirmed submission format are intentionally flagged for you to complete — they are not auto-filled.
KEV looks out of date.
Check the snapshot date shown on the register. The snapshot advances with app updates; for the very newest entries, cross-check the authoritative public source.
I can't find an export button in the free tier.
Export is a paid-plan feature; the Readiness Check is preview-only.

Questions not covered here: see the Support & FAQ page or email support@complydraft.com.