What an auditor, or Sekit's evidence engine, asks for.
Secure development policy
The rules the development team follows to build software securely: security requirements, code review and threat modeling.
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
Environment separation is easy to state and easy to quietly erode: a developer with production database access left over for debugging, or a test environment seeded with a copy of real customer data because generating realistic test data takes longer. Auditors check the change and release records to confirm production changes go through review and approval rather than a direct push from a laptop, and look at whether outbound data protection features are configured to catch sensitive data moving into a lower environment. Penetration testing needs the same discipline in reverse, isolating targets so testing does not touch production availability. The gap that recurs most is a staging database still populated with unmasked customer records from months ago.
Common gaps
The staging environment is seeded with an unmasked copy of the production customer database, refreshed monthly with no masking step applied.
A developer retains standing production database access left over from an incident months ago, with no ticket documenting why it was never revoked.
A hotfix went straight into production during an incident, skipping the test environment, and no one logged the emergency change or later reviewed it.
Questions your auditor will ask
Is test data masked or is it real customer data?
Test environments run on masked or synthetic data rather than a raw copy of production, and outbound data protection technology flags any unmasked customer data trying to move in, with confirmed attempts followed up.
Can code reach production without passing through the test environment first?
No. Every change goes through the test environment first: release management requires it to pass testing and approval, and the pipeline blocks any build that has not cleared its checks, before it can reach production.
How is penetration testing kept from affecting production availability?
Testers target an isolated staging replica rather than live systems, and any production-adjacent run happens in an agreed maintenance window with a rollback plan ready if something goes wrong.
Where regulation demands it
NIS2 art. 6.2 requires a secure development life cycle that keeps development activity separate from production, and ENS mp.sw.2 requires formal acceptance before software is put into service in production.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.