Article 24 Obligations of open-source software stewards

A steward needs the policy itself, kept in a version-controlled form with dates and approvals, plus the records that show it is followed. Under Article 24(1), the policy must be documented in a verifiable manner, so an assessor will expect to see the policy text, its revision history, the owner who approved each version, and proof that the policy was in force on the dates in question. Keep the policy, the role records, the intake and triage log, remediation records, scan outputs, release notes and any authority correspondence in one controlled repository with a clear index. Confirm the exact format and retention period with your national market surveillance authority, since the regulation sets the duty to document but leaves the form to the steward.

Record who owns each step of vulnerability handling, who can approve a release, and who speaks for the project to authorities. A short responsibility matrix works well: name each role, the person or group holding it, its duties under the policy, and the date the assignment took effect. Review the matrix whenever maintainers change, and keep the previous versions so you can show who held a role at a given time. The matrix is the first artifact most assessors read, because it shows whether the policy has an owner or only a document.

Intake and triage logs show that reports are received, assessed and tracked to a decision. Each entry should record when the report arrived, its source, the affected component and version, the severity assessment, who triaged it, the decision taken and the reasoning. Keep entries for reports that were rejected as well, with the rationale, because an authority may ask how the steward handled unfounded reports. Tools such as the issue tracker of your own forge or a findings platform can hold these records, but the policy should name the system of record and how entries are protected from later edits.

Scan and dependency review outputs prove the steward looks for vulnerabilities on a set schedule and acts on the results. Keep dated scan reports, the scope of each scan, and the review notes that record which findings were confirmed, suppressed or deferred. For self-hosted tooling, Greenbone Community Edition (OpenVAS) stores scan results in PostgreSQL and schedules scan tasks, which gives a usable history of runs. DefectDojo imports findings from more than 500 security tool report formats and deduplicates them with per-tool hashcode fields, so one register can show findings across tools over time. Document the scan frequency in the policy and check that the stored history matches it.

Remediation records link each confirmed vulnerability to the change that fixed it, the release that shipped the fix, and the date of disclosure or advisory where one was issued. An assessor will test a sample: pick a finding, then trace it from intake to fix to release. Keep these links in the tracker and in the release notes, and record any vulnerability that was not fixed, with the reason and the mitigation offered. Version control history helps here, since commit messages and tags can point back to the finding identifier.

Release notes should state which security fixes each version contains and link to the related advisory. Publish them with each release rather than assembling them later, and keep the archive of past notes unchanged so the record stays accurate. Where a steward supports several branches, note which branches receive each fix. Keep a dated copy of each advisory as issued, so later edits do not change what users were told at the time.

Keep every request from a market surveillance authority, the date it arrived, the documents you provided under Article 24(2), and the full correspondence. Under that paragraph, stewards must cooperate with authorities on request and provide policy documentation on a reasoned request, so the record should show the request's stated grounds, what was sent, when, and any follow-up. Store these in a restricted location with an index, and make sure the policy names the contact who receives such requests. Confirm with the relevant authority how it expects requests to be handled, because practice may differ between Member States.

Attach evidence capture to routine work instead of preparing it for an audit. Set a recurring review for the policy and the responsibility matrix, make scan runs and triage logging part of the normal workflow, and tie release notes to the release process so they cannot ship without an entry. A monthly or quarterly internal check that samples one finding through the full chain is a practical way to confirm the records still connect. The cost is mostly staff time for upkeep, which recurs, so ask any implementation partner to define these routines in writing and to hand over the templates and tooling configuration. DeployOpen can set up and document self-hosted systems for this work under a written, fixed scope, but it does not assess or certify the policy, and an independent authority or assessor reviews the evidence.

No. Article 24(1) requires the steward itself to put in place and document a cybersecurity policy, so the policy has to be owned by the project or foundation. An outside firm can help draft the policy, map it to how the project actually develops and releases code, and check that the written process matches practice. The steward remains responsible for approving it, keeping it current and showing it to market surveillance authorities on reasoned request under Article 24(2). Ask any provider to confirm in writing which parts it drafts and which parts the steward's maintainers must approve and operate.

Writing the policy is usually the shorter part. The longer effort is operating it: recording how vulnerabilities are documented, triaged, fixed and shared, and keeping those records in a form you can verify later. The time to write depends on how many repositories the steward supports, how formal the existing release process is and how many maintainers must review the text. The Commission's guidance on applying the regulation, published as an annex to C(2026) 5252, describes the steward role, but it does not set a fixed duration. Ask for a timeline that separates drafting, review and the first operating cycle.

The engagement needs people who know how the project really works. Expect to need maintainers who understand the release process, someone who owns the vulnerability intake channel, and a decision-maker who can approve the policy for the foundation or legal entity. Access to the issue tracker, security advisories, dependency manifests and build pipeline is also needed so the policy can be checked against real records. Plan for maintainer time in review sessions. If your volunteers are the bottleneck, agree that scope and sign-off in writing before work starts.

Often yes, especially where a foundation has staff who already run security processes. In-house work is practical when the team can draft a policy, track vulnerability records in a consistent system and answer authority requests without delay. Outside help tends to be more useful when the project lacks a documented process, has many repositories with different maintainers, or needs a neutral review before publication. The decision depends on your current records, not on the regulation alone. A self-assessment against the Article 24 duties will show which gaps are small enough to close internally.

No certification is defined for open-source software stewards under the regulation, and no notified body or independent certifier is set up for the steward duties. The obligations are to document the policy in a verifiable way, cooperate with market surveillance authorities and, from 11 December 2027, report actively exploited vulnerabilities and severe incidents within the limits of Article 24(3). Some stewards may still commission an independent review to gain assurance for customers, but that review is a voluntary choice, not a regulatory certificate. Be cautious with any provider that describes a steward certificate as required.

Article 64(10)(b) excludes administrative fines for any infringement of the regulation by open-source software stewards. That exclusion is a significant difference from the regime for manufacturers, which faces fines under Article 64 of up to EUR 15 million or 2.5% of total worldwide annual turnover for breaches of Annex I and Articles 13 and 14. The exclusion does not remove the duties themselves. Stewards must still document the policy, cooperate on request and report within scope. Authorities can act through other measures, and a steward that also sells a commercial product may be a manufacturer for that product.

The line depends on what the entity does with each product. A legal person that sustainably supports a free and open-source product intended for commercial use, without placing it on the market, is a steward for that project. Commission guidance C(2026) 5252 (section 3.3) gives the example of a company that publishes a free community version and a monetized version: it is a steward for the first and a manufacturer of the second. Map each product line before you scope an engagement, because the manufacturer duties carry fines and a wider set of obligations.

Most DeployOpen engagements are fixed-scope, meaning the scope, deliverables and timelines are agreed in writing before work starts. For a steward, a typical written scope would list the repositories and projects covered, the vulnerability intake and disclosure workflow to document, the records to keep, and the review cycles. DeployOpen can also help configure self-hosted tooling inside your own infrastructure to hold those records, such as wiki-based policy documents with version history or a findings tracker that imports scanner output. DeployOpen does not issue reports or attestations, and the steward remains responsible for its own policy. Ask for the written scope and a quote that follows from it.