What an auditor, or Sekit's evidence engine, asks for.
CI/CD pipeline security
The security controls in the automated build-and-deploy process, including containers and infrastructure-as-code.
Change and release management records
The process to review and approve changes to production systems before applying them, and how new versions are released in a controlled way.
From the Sekit evidence catalog
In practice
Change management works when the approval step is technically enforced, not only written into a procedure that busy engineers route around under deadline pressure. Auditors want to see the change and release records showing review and approval before production changes, matched against the asset repository to confirm it was updated as part of the same change rather than months later during a stock-take. Deployments should run through a pipeline that produces repeatable releases with a fast rollback path, because a change that cannot be reversed quickly turns a minor mistake into an extended outage. The recurring gap is an emergency change process used for routine work because the standard approval flow feels too slow.
Common gaps
The emergency change process, meant for genuine incidents, is used routinely for changes that could have gone through standard review and approval instead.
Deployment pipeline technical controls block unauthorized changes, but a handful of admins retain direct production access that bypasses the pipeline entirely.
The asset repository is updated inconsistently after changes, so several production systems no longer match their recorded configuration.
Questions your auditor will ask
Does every change to production go through review and approval first?
Yes, no change reaches production systems without prior review and approval, and who may approve what is defined in writing.
What happens if a released change causes a problem?
Deployments run through a pipeline that produces repeatable releases and can roll back to the previous working version quickly when a release goes wrong.
How do you keep your asset records accurate as changes happen?
The asset repository is updated as a routine part of every change, so records of assets, configurations and their relationships stay current.
Can an unapproved change reach production, or only get flagged after the fact?
The change workflow is enforced technically so unapproved changes to production are blocked rather than merely discouraged by policy.
Where regulation demands it
NIS2 art. 6.4 requires a controlled process for change management, repairs and maintenance, and ENS op.exp.1 requires an accurate asset inventory kept current through that same process.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.