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, and the software bill of materials. 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 four 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, which products you have registered, and the support period you have declared. Every decision that only you can make is marked [TODO] in the text. Nothing is hidden and nothing is invented on your behalf.
The four 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 |
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.
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 every night.
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.
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.
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.