On this page
- Review independent readiness dimensions instead of averaging them.
- Identify the release and freshness of the evidence behind each result.
- Repeat checks after relevant changes, not only at calendar intervals.
- Keep reporting operations live between scheduled reviews.
What a readiness check can establish
A readiness check can establish what evidence was reviewed, which questions remain open and whether the responsible people have recorded their decisions. It can also expose a stale inventory, an unavailable intelligence source or a reporting task with no owner. Its result is bounded by the product, release, inputs and method used.
It cannot establish product security simply by finding policy files, nor legal conformity by counting completed tasks. CRA manufacturer responsibilities extend across design, documentation and ongoing vulnerability handling. Treat the check as a way to inspect that work, not a substitute for it.
Read the result in separate dimensions
Use separate views for evidence coverage, accountable approvals, security intelligence and operational readiness. Access or data availability is another condition: if a view is locked or a request failed, the missing result is unknown, not zero. The following is a suggested review structure, not a regulator scoring method.
| Dimension | Question | Useful next action |
|---|---|---|
| Evidence | Does current material support the requirement? | Obtain, replace or review the evidence |
| Approval | Has the accountable person accepted this conclusion? | Resolve the pending decision |
| Intelligence | Was the inventory checked successfully and recently? | Restore coverage or investigate findings |
| Reporting | Are live milestones owned and recorded? | Submit, escalate or retain the receipt |
| Availability | Can the reviewer access the complete result? | Resolve access or data failure |
Ask what has changed since the baseline
At a release review, compare product functions, dependencies, tests, user instructions and support assumptions against the last completed baseline. A new customer-hosted edition or privileged agent may change the scope analysis. A dependency update may require new affectedness review. A policy wording change may simply improve an explanation without changing the underlying control.
Keep those distinctions in the record. Reusing evidence can be sensible where its relevance is explained. Copying the previous approval into a different context without checking the facts is not the same thing.
Use the check to prioritise a concrete work queue
Imagine a team preparing a maintenance release. The inventory is current, an updater test has failed, the classification approval is pending and the reporting deputy has left the company. The next move is not to calculate an average. Engineering owns the updater fix, the approver resolves the category decision and the reporting owner appoints and trains a deputy.
For each item, retain its scope, owner, reason, expected evidence of completion and review point. A deadline is useful only if the team can act on it. Avoid effort estimates generated from the mere presence of a gap; the complexity depends on the product and the work required.
Check reporting readiness without delaying live action
A scheduled review should verify contacts, access, escalation rules and recent drill findings. It should also inspect live cases for outstanding milestones. Keep a drill separate from a real case and a completed submission separate from a draft.
The 24-hour and 72-hour Article 14 limits are not a reason to wait until the next readiness meeting. Use the deadline-tracking process when a potential trigger arises. The review then checks whether the process operated, including the evidence behind the awareness time and external receipt.
Repeat at meaningful points
Review after relevant release changes, newly understood vulnerabilities, changes to product scope or support, and changes in responsible people. A periodic review can catch neglect between those events. Choose its frequency based on release cadence and product risk; do not present an editorial weekly or monthly routine as a CRA-mandated schedule.
ConformOps's readiness overview separates these dimensions and preserves the latest attempt alongside the last completed baseline. Use it to find the owning workflow, then inspect the evidence. The in-house setup guide explains how to establish the responsibilities that make recurring checks useful.
Frequently asked questions
Does a high readiness score mean a product complies?
No. A score can hide missing evidence, approval or operational work. Review each dimension and the underlying evidence for the relevant product and release.
How often should we run a CRA readiness check?
Use relevant changes and security events as triggers, with a periodic review to catch neglected work. The appropriate cadence depends on the product and process; this guide does not prescribe a legal weekly or monthly interval.
Can we reuse evidence from a previous release?
Where it remains relevant, explain that relevance and retain the original scope. Changed facts or controls may need new evidence and renewed approval.