The default checklist

Every project starts with this eight-item checklist, five required and three optional. It comes from measure op.exp.5 "Gestión de cambios" (change management) of Spain's Esquema Nacional de Seguridad (ENS, Royal Decree 311/2022, Annex II), from the evidence proposed by its audit guide, CCN-STIC 808 (April 2026 edition, op.exp.5 sheet), and from control 8.32 "Change management" of ISO/IEC 27002:2022, which expands on control A.8.32 in Annex A of ISO/IEC 27001:2022.

Next to each item is where it comes from: which requirement or control asks for it. That explains why it is on the list, not that ticking it is enough: a ticked item records who says they did it and when, but it does not by itself show that it was done well or that the organisation meets the requirement. That is for the auditor to assess, with the evidence each item asks you to link in the issue.

The project administrator can change the checklist: remove, edit or add items (up to twelve) and decide which are required (Administration). The ENS requirements are official only in Spanish: below is a summary of each, with its reference; the full text is on the Spanish version of this page. ISO/IEC 27002 control titles are given in their original English.

Measure op.exp.5 applies to systems of MEDIUM and HIGH category; its reinforcement R1 ("Prevención de fallos", failure prevention), only to HIGH category systems.

1. Change risk level assessed (LOW, MEDIUM, HIGH) and, if HIGH, prior approval by the Security Officer recorded

Required. In Lacre, the risk is always chosen in the panel, and the project can require a high-risk change to have its prior approval sealed before the check ("Require prior approval for HIGH risk"): that way the approval is recorded with who, when and with which role.

• ENS, [op.exp.5.4]: a risk analysis determines whether changes are relevant to the security of the system, and HIGH-risk changes must be explicitly approved by the Security Officer before they are implemented.
• CCN-STIC 808, proposed evidence: reports of the risks associated with changes, and evidence of the additional prior approval of HIGH-risk changes by the Security Officer.
• ISO/IEC 27002:2022: 8.32 Change management.

2. Security impact documented in the issue

Required. The assessment of the security impact is written in the issue itself (in the description or a field), so that it is part of what is sealed.

• ENS, [op.exp.5.4]: a risk analysis determines whether changes are relevant to the security of the system.
• ENS, reinforcement R1, [op.exp.5.r1.3]: every change to the system is documented, including an assessment of its impact on the security of the system.
• CCN-STIC 808, proposed evidence: documentation of the impact of changes on the security of the system.
• ISO/IEC 27002:2022: 8.32 Change management.

3. Tests run in an environment separate from production, with the results linked

Required. The test results (a report, the continuous integration run) are linked in the issue before ticking the item.

• ENS, [op.exp.5.3]: pre-production tests, whenever they can be done, are run on equipment equivalent to production, at least in the aspects specific to the change.
• CCN-STIC 808, proposed evidence: pre-production test reports.
• ISO/IEC 27002:2022: 8.31 Separation of development, test and production environments, 8.29 Security testing in development and acceptance and 8.32 Change management.

4. Acceptance tests run, with the results linked

Required. Acceptance tests are run once the change is implemented; their results are linked in the issue.

• ENS, [op.exp.5.5]: once the change is implemented, the appropriate acceptance tests are run and, if they pass, the configuration documentation is updated where relevant.
• CCN-STIC 808, proposed evidence: acceptance test reports.
• ISO/IEC 27002:2022: 8.29 Security testing in development and acceptance and 8.32 Change management.

5. Rollback plan written

Required. How to undo the change if it goes wrong, written before it is applied. The ENS only asks for it in HIGH category (reinforcement R1); in the default checklist it is required as good practice.

• ENS, reinforcement R1, [op.exp.5.r1.1]: before changes are applied, the possibility of reverting them if adverse effects appear is taken into account.
• CCN-STIC 808, proposed evidence: a rollback plan for a change.
• ISO/IEC 27002:2022: 8.32 Change management.

6. Configuration and inventory updated

Optional. Ticked when the change requires updating the documented configuration or the asset inventory and that has been done.

• ENS, [op.exp.5.5]: once the change is implemented and the acceptance tests pass, the configuration documentation (network diagrams, manuals, the inventory) is updated where relevant.
• CCN-STIC 808, proposed evidence: configuration updates (inventory, manuals, network diagrams) after an implemented change.
• ISO/IEC 27002:2022: 8.9 Configuration management and 5.9 Inventory of information and other associated assets.

7. Affected parties informed of the change

Optional. Those who use or depend on the service know about the change and when it happens. The CCN-STIC 808 sheet proposes no evidence of its own for this; among its questions for the auditor is whether maintenance windows agreed with the users have been defined.

• ENS, [op.exp.5.1]: changes are planned to reduce the impact on the services affected, and every change request is registered with a reference number that allows it to be tracked.
• ISO/IEC 27002:2022: 8.32 Change management.

8. Operating documentation updated

Optional. Ticked when the change requires updating the operating manuals or procedures and that has been done.

• ENS, [op.exp.5.5]: once the change is implemented and the acceptance tests pass, the configuration documentation, including manuals, is updated where relevant.
• CCN-STIC 808, proposed evidence: configuration updates (inventory, manuals, network diagrams) after an implemented change.
• ISO/IEC 27002:2022: 5.37 Documented operating procedures and 8.32 Change management.

What the checklist does not cover

The CCN-STIC 808 proposed evidence for op.exp.5 also includes the register of change requests (in Jira, the issue itself, with its key as the reference number), the minutes of the change advisory board, if there is one, and the reporting of failures to the Security Officer. Lacre does not produce them: if the project needs them for every change, it can add its own items to the checklist.