Policy Library and Personnel
The Cyber Resilience Act expects written policies, and it expects them to be maintained. Annex I Part II and Article 13 between them assume a manufacturer has a documented approach to secure development, vulnerability handling, incident response, the software bill of materials, and the support period. Most small manufacturers have none of these written down, not because they do not do the work, but because nobody has ever had to produce the document. The Policy Library turns that from an essay into a form you fill in.
Each of the five policies arrives already drafted from what the Portal already knows about your organisation: your company name, your public reporting URL, whether you have published a PGP key, and the support period you have declared. The policies do not list your products by name. They refer to your product register, so a policy stays correct when you add, rename or withdraw a product. Every decision that only you can make is marked [TODO] in the text. Nothing is hidden and nothing is invented on your behalf.
The five policies
| Policy | What it covers | Basis |
|---|---|---|
| Secure development policy | How products are designed, reviewed, tested and released | Article 13(1) and (2), Annex I Part I(1) |
| Vulnerability handling policy | How reports are received, triaged, remediated and disclosed | Annex I Part II, Article 13(6) |
| Incident response plan | Who is called, who decides, what gets reported and by when | Article 14(3) |
| SBOM management policy | How the bill of materials is produced, kept accurate and acted on | Annex I Part II(1), Annex VII |
| Support period policy | How the support period is set, how buyers see its end date, how long security updates stay available, and what users are told when support ends | Article 13(8), (9) and (19) |
A template is a starting point, not legal advice, and publishing one is not a declaration of conformity. Read what it says before you approve it.
When a template changes, a policy that you already adopted keeps its text. The Portal does not change a policy after you adopt it. Read the release notes and update your policy yourself.
Editing and preview
Policy text is written in Markdown. The generated templates already use it for their headings, tables and the bracketed [TODO] prompts, so you rarely need to write any yourself, but the usual ## headings, - lists and | tables all work if you want to add a section.
One toggle above the text box switches between Edit and Preview. Edit shows the source you type. Preview shows the document exactly as the reader will see it, which is the same rendering used on the acknowledgement page, so what you check before publishing is what the person signing will read.
Text you must change before publishing
The editor marks the text that is not ready to publish, in Edit and in Preview.
- A dashed box marks text to complete. These are the
[TODO]prompts and any[Your ...]value the Portal did not know, such as a missing portal URL. Replace each one with your own decision. - A line through the text marks text to remove. This is the "DRAFT generated by CVD Portal" note at the end of every new policy. Delete it, and the
---line above it, when the policy is final.
Below the text box, a line shows how many items are left of each kind. Go to next selects the next marked item in the text box. The marks are an editing aid only. The published policy and the acknowledgement page do not show them.
The lifecycle
A policy moves through five states.
Draft. The working copy. Edit it freely.
In review. Optional. Use it when somebody other than the author needs to look before approval.
Approved. A named person has read this exact text and signed off. Editing the body of an approved policy sends it back to draft and drops the approval, because an approval that survives an edit is a signature on a document nobody read.
Published. The text becomes an immutable revision with a version number. This is the point at which the policy counts as evidence.
Archived. Retired. The text stays exactly as it was.
Publishing does three things at once. It writes the revision, it opens a fresh round of acknowledgements, and it marks the CRA obligations the policy discharges as satisfied. Those obligations then appear as complete in the obligation matrix and in the control register, with a note pointing back at the policy that discharged them.
Personnel
The people who have to acknowledge a secure development policy are engineers, and in a twelve-person manufacturer most of them will never hold a dashboard login. The personnel roster under Settings → Personnel is a list of named people, not a list of users. Adding somebody needs only a name and an email address.
Each person on the roster receives a single-use link when a policy is published. The link opens a page showing the exact published text, and confirming there records their acknowledgement against that specific version. There is no account to create and no password to remember.
Three things follow from that design.
Acknowledgement is recorded against a revision, never against a policy. Publishing a new version starts a fresh round, because "Anna acknowledged the incident response plan" is worthless if the plan changed afterwards.
Somebody added to the roster after a policy was published is enrolled straight away, with their own deadline running from the day they were added rather than from the original publication. A new engineer who never saw the policy is exactly the gap this closes.
A leaver is marked inactive rather than deleted. Their past acknowledgements stay resolvable to a name, and their outstanding requests are withdrawn so a policy does not sit permanently incomplete waiting for a signature from somebody who left.
If a signature was collected on paper, an admin can record it from the policy page. It is stored as "recorded by an admin" rather than as a self-service acknowledgement, so an attestation by a third party is never mistaken for the person acting for themselves.
What keeps it honest
A policy written once and never revisited is worth nothing to an auditor. Every published policy carries a review interval, twelve months by default, and the Portal checks the clock once a day.
Two automated checks run against each policy and feed the control register.
Published and in review. Passes when the policy has been published and its published text has not passed its review date. Fails once the review lapses, which turns the associated obligation red even though the box is still ticked. That is deliberate: the tick says somebody satisfied the obligation, and this says the document behind it went stale eleven months ago.
Acknowledged by the people asked. Passes when everyone asked has acknowledged the current revision, or is still inside their deadline. Fails when somebody is past their deadline, and fails when acknowledgement is required but nobody is on the roster. This check turns only the policy control red. The obligation that the policy discharges keeps its status. The obligation asks whether the document exists and is current. Whether your staff acknowledged it is a question about the policy.
Neither check fails for a policy you have not adopted. An unadopted template shows as not started in the register, which is a maturity gap rather than a control failure, and painting it red would be reporting the same gap twice.
Both checks run once a day, at 07:35 UTC. Recording an acknowledgement or publishing a policy does not run them again. A control that is red in the morning stays red until the next run, even after you fix the cause. A late acknowledgement counts as given, so the acknowledgement check passes at the first run after it is recorded. The control register shows when each check runs next. The control register lists the ID of each check and what to do when one fails.
Availability
The Policy Library is included from the Reporting plan upwards. Adopting, editing, approving, publishing and managing the roster require an account admin. Members can read every policy.