CUP FIELD TOOLS · CRA product readiness

Can your product team show the evidence behind its CRA plan?

Review one product and market activity under the Cyber Resilience Act. Establish scope and responsibilities, then identify gaps in product security, vulnerability handling, reporting readiness and the supporting dossier.

12 chapters · 37 detailed verifications · Initial and detailed review modes · No account required

Start the evidence review →

WHY USE IT?Turn a regulatory workstream into owned evidence requests.

Use a concrete product baseline to separate applicability questions from engineering and response work. Bring the product, security and regulatory teams a shared list of records to obtain, decisions to resolve and actions to track.

YOUR REVIEW PATH

Scope → Evidence → Action

A focused review with an accountable outcome.

Product & roleDefine the reviewed scope

Review ↗

Product & response evidenceChallenge the supporting records

Review ↗

Readiness decisionAssign the unresolved actions

Review ↗

Your exportable action plan

Missing records · Owners · Next steps

Illustrative review flow. Select a checkpoint to explore it.

How to use this review

Bring the right people: product, security engineering, vulnerability-response and regulatory roles. Record roles and non-sensitive references.

Define one decision. Record the baseline, applicable basis and accountable owner. Identify uncertain applicability before treating requirements as settled.
Challenge the evidence. Work through twelve questions. Reference existing records, explain what they demonstrate and leave unsupported conclusions open.
Take an action plan to the review. Export a report or CSV, assign owners and dates, and save a review file to update later.

The first pass identifies missing work. It does not complete the underlying assessment, tests or regulatory review. Use “Not applicable” only with a recorded rationale.

SCOPE AND REFERENCE BASIS · REVIEWED 1 NOVEMBER 2026

Agree the basis before relying on the result.

Confirm scope, exclusions, economic-operator role, product category and application dates before relying on this review. CRA Article 14 reporting obligations apply from 11 September 2026; most provisions apply from 11 December 2027. Review transitional rules for existing products separately. Those dates do not establish that a particular product is in scope. This worksheet neither chooses the conformity route nor submits regulatory reports.

CUP’s questions are original engineering review prompts, not a reproduction of standard clauses, a complete legal checklist, a certification or legal advice. Record the applicable text, edition, jurisdiction and review date; seek qualified interpretation where needed.

BEFORE YOU START · YOUR DATA

Use references, keep sensitive information in your own systems.

This worksheet runs in your browser. Answer the checkpoints, reference your existing records and export the resulting action plan when you need it.

Saved in this browser · No upload of worksheet entries to CUP · Use non-sensitive references only. Downloaded files contain your entries; check them before sharing.

Read how saving, deletion and exports work

What to enter: fictional or non-sensitive review references, job roles and short action descriptions. For example, “Review record R-042” and “Accountable review owner”.
What to leave out: passwords, keys, tokens, personal data, IP addresses, network diagrams, unpublished vulnerability details, incident details and confidential system, product or supplier information. Keep the evidence itself in your organisation’s approved systems.
Where entries are saved: automatically in this browser profile on this device, when local storage is available. Worksheet entries and imported review files are not uploaded to CUP. There is no account-based backup or synchronisation. Other people using the same profile, and software with access to it, may be able to read them. This is not an encrypted vault.
How to remove them: choose “Clear saved review” in the workspace. Clearing this site’s browser data also removes the local review. Download a copy first if you need to keep it. Browser data can be lost or cleared.
Exports and sharing: downloaded reports, CSV and review files contain your entries and are not encrypted by this tool. Printing or saving a PDF creates another copy. Check every copy before sharing and store it according to your organisation’s rules. Clearing the worksheet does not delete downloads, backups or copies you have shared.

The worksheet supports an evidence review. Your authorised team remains responsible for verifying evidence and deciding the appropriate next decision. See the site privacy notice for information about visiting CUP.

Before design or procurement

Agree the scope, responsibilities and evidence to request before accepting a supplier or solution claim.

Before release or deployment

Check the current baseline and unresolved conditions with the authorised decision owner.

After a material change

Reopen the review when the use, configuration, evidence, legal basis or supporting assumptions change.

Build your action plan →

Twelve evidence checkpoints

Read or print this table without JavaScript. Guided saving and exports require JavaScript. Keep sensitive evidence in approved systems; use non-sensitive references here.

CRA product readiness · original CUP review prompts
Checkpoint	Evidence to assemble	Decision to resolve	Review notes
01 · Product and market scope	Product functions, connectivity, remote processing dependencies, market placement and exclusion analysis. Detailed verifications (3) Suggested review roles: Product owner; qualified regulatory reviewer. Lifecycle: Product/activity applicability. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Product functions identified Evidence to request: Product-scope record. Document only when: The reviewed product and relevant dependencies are explicit. Market activity examined Evidence to request: Market-placement assessment. Document only when: The activity and its connection to scope are reviewed. Exclusions justified Evidence to request: Applicability review. Document only when: Any asserted exclusion has a recorded qualified rationale.	Is this product and activity within the reviewed CRA scope?	Evidence assembled
02 · Economic-operator responsibilities	Manufacturer, importer, distributor or other relevant role, supply-chain relationships and accountable contacts. Detailed verifications (3) Suggested review roles: Relevant economic operator; supply-chain owner. Lifecycle: Role and responsibility allocation. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Role established Evidence to request: Economic-operator assessment. Document only when: The organisation’s role follows its actual activity. Supply-chain responsibilities assigned Evidence to request: Responsibility register. Document only when: Relevant handovers and escalation owners are explicit. Role-changing actions considered Evidence to request: Branding or modification review. Document only when: Potential changes of responsibility are assessed.	Which obligations belong to this organisation in this activity?	Evidence assembled
03 · Applicable provisions and timing	Current legal text, transition analysis, product placement dates and reporting-readiness review. Detailed verifications (3) Suggested review roles: Regulatory reviewer; response owner. Lifecycle: Application dates and transition review. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Current text identified Evidence to request: Legal-basis register. Document only when: Binding text is distinguished from guidance or proposals. Application dates reviewed Evidence to request: Timing assessment. Document only when: Applicable provisions and transition treatment are separated. Reporting readiness reviewed separately Evidence to request: Article 14 readiness decision. Document only when: An older placement date is not used as the sole reason to dismiss reporting readiness.	Which obligations apply now and which preparation milestones remain?	Evidence assembled
04 · Product category and assessment route	Intended purpose, category analysis, applicable implementing measures and conformity-assessment rationale. Detailed verifications (3) Suggested review roles: Product regulatory owner; assessment lead. Lifecycle: Category and assessment-route selection. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Intended purpose reviewed Evidence to request: Category assessment. Document only when: Classification uses the actual product purpose. Current category rules checked Evidence to request: Implementing-measure register. Document only when: The reviewed basis is dated and traceable. Assessment route justified Evidence to request: Conformity route decision. Document only when: The route follows the applicable category analysis.	What supports the chosen product category and assessment route?	Evidence assembled
05 · Product cybersecurity risk assessment	Intended and foreseeable use, threat paths, dependencies and design-risk decisions. Detailed verifications (3) Suggested review roles: Product security architect; risk owner. Lifecycle: Product cybersecurity risk assessment. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Product use examined Evidence to request: Product risk assessment. Document only when: Intended and foreseeable use inform the reasoning. Dependency threats considered Evidence to request: Threat and dependency review. Document only when: Inherited weaknesses are included in the scope. Design decisions linked Evidence to request: Risk treatment trace. Document only when: Security choices have product-specific justification.	Does the assessment explain the product’s cybersecurity design choices?	Evidence assembled
06 · Security requirements and verification	Applicable essential requirements, implementation evidence, secure configuration and verification results. Detailed verifications (3) Suggested review roles: Requirement/verification owners; product security. Lifecycle: Design and released-build verification. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Applicable requirements identified Evidence to request: Requirements register. Document only when: Inclusions and exclusions have reasons. Released implementation examined Evidence to request: Build-specific verification. Document only when: Evidence covers the delivered baseline. Gaps treated explicitly Evidence to request: Requirement-gap review. Document only when: Unproven conditions have owners and next steps.	What demonstrates the relevant product security requirements on the released build?	Evidence assembled
07 · Components and dependency knowledge	Component inventory, supplier inputs, inherited vulnerabilities and dependency-review records. Detailed verifications (3) Suggested review roles: Inventory owner; supplier manager. Lifecycle: Dependency review and vulnerability intake. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Inventory usable Evidence to request: Component inventory reference. Document only when: The team can identify security-relevant dependencies. Supplier evidence assessed Evidence to request: Supplier review record. Document only when: Upstream limitations are not hidden by an inventory entry. Findings routed to triage Evidence to request: Dependency finding sample. Document only when: A representative finding reaches an owned decision.	Can the team identify which supplied components affect product security?	Evidence assembled
08 · Vulnerability handling and disclosure	Intake channel, validation, coordinated disclosure, remediation and supplier escalation procedures. Detailed verifications (3) Suggested review roles: Vulnerability-response lead; supplier contact. Lifecycle: Intake, remediation and disclosure. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Intake operational Evidence to request: Intake exercise reference. Document only when: A report reaches someone who can assess it. Remediation coordinated Evidence to request: Response workflow sample. Document only when: Validation and disclosure responsibilities are assigned. Supplier constraints escalated Evidence to request: Escalation record. Document only when: Missing support produces an owned response rather than a dead end.	Can a reported weakness reach an owned response decision?	Evidence assembled
09 · Reporting readiness	Reportability assessment process, current deadlines and channels, duty coverage and evidence-preservation plan. Detailed verifications (4) Suggested review roles: Reporting decision owner; duty response team. Lifecycle: Reportability assessment and reporting readiness. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Reportability assessed Evidence to request: Current reporting procedure. Document only when: The team can identify who assesses possible reportability. Deadlines and channels current Evidence to request: Authoritative reporting-basis record. Document only when: The relevant process uses a reviewed current basis. Duty coverage exercised Evidence to request: Timed tabletop record. Document only when: Out-of-hours and supplier delays are considered. Submission authority assigned Evidence to request: Reporting responsibility record. Document only when: An accountable role can act without treating this worksheet as a submitted report.	Can the team assess and escalate a potentially reportable event in time?	Evidence assembled
10 · Support period and security updates	Support-period rationale, user information, update delivery and vulnerability-remediation resources. Detailed verifications (3) Suggested review roles: Product support owner; update engineering. Lifecycle: Support commitment and update operation. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Support rationale documented Evidence to request: Support-period assessment. Document only when: The declared period has a product-specific basis. Commitment communicated Evidence to request: Published support information. Document only when: User-facing information matches the reviewed commitment. Update capability sustained Evidence to request: Maintenance resource plan. Document only when: The organisation can support the promised security handling.	Can the promised support and update handling be sustained?	Evidence assembled
11 · Technical documentation and market information	Technical file index, conformity route evidence, declaration and marking review where applicable, user information and records retention. Detailed verifications (3) Suggested review roles: Technical-file custodian; regulatory signatory. Lifecycle: Dossier and market-information review. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Evidence locatable Evidence to request: Technical-file index. Document only when: A reviewer can find the relevant supporting records. Formal steps reviewed Evidence to request: Conformity documentation review. Document only when: Required declaration or marking steps are distinguished from plans. User information checked Evidence to request: Product information review. Document only when: The supplied information matches the product and applicable basis.	Can a reviewer locate the evidence behind the market-facing claim?	Evidence assembled
12 · Release, monitoring and reassessment	Owned release decision, unresolved gaps, post-market monitoring and modification triggers. Detailed verifications (3) Suggested review roles: Release owner; post-market response lead. Lifecycle: Release, monitoring and modification review. Assess each verification for this chapter’s actual scope and the role responsible for it. Record the applicable requirement/decision reference; any N/A needs a specific reason. These are CUP engineering prompts, not a complete normative inventory. Release conditions owned Evidence to request: Release-readiness record. Document only when: Outstanding conditions have an authorised decision owner. Post-market findings acted on Evidence to request: Monitoring response record. Document only when: New evidence can trigger action. Material changes reassessed Evidence to request: Modification review trigger. Document only when: Scope, category and assessment implications can be revisited.	Who decides whether the product evidence needs to be reopened?	Evidence assembled

PRIMARY REFERENCES · REVIEWED 1 NOVEMBER 2026

Check the source and its applicability.

Public catalogue and guidance links support orientation. Licensed standards and legally authentic texts govern their respective requirements. This worksheet does not establish equivalence between standards and regulations.

CRA — Regulation (EU) 2024/2847

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

Commission — CRA summary and application dates

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

Commission — CRA implementation resources

Use the official source to check the relevant scope, current text and applicable conditions.

Open official reference →

All six worksheets →Comparative evidence map →