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.
Zero Trust and advanced detection
The advanced network-security and detection approaches: Zero Trust access (never trust by default), behavior analytics (UEBA), and custom detection engineering.
From the Sekit evidence catalog
In practice
Secure architecture principles are easiest to state and hardest to keep current. An SME might document a secure-by-design checklist for new systems, but the checklist covers only web applications, not the new IoT sensor line or a vendor-hosted CRM integration. Privacy defaults, minimal data collection, limited retention, get built into the flagship product but not into the internal dashboard someone spun up over a weekend, which exports everything by default because that was the easiest option under deadline pressure, and nobody circled back to apply the same engineering principles to it afterward.
Common gaps
Secure design principles are documented for the main product but not extended to internal tools, acquisitions or newly adopted vendor platforms.
Privacy-protective defaults exist in the primary application, but new internal systems default to collecting more data than necessary.
Safety validation for operational technology changes is informal, so security controls have been deployed without confirming they cannot disrupt production processes.
Questions your auditor will ask
Are security principles applied only to new systems or also to significant changes?
Both, threats are identified and documented before development starts on new applications and before major changes to existing ones.
What does privacy by design mean in practice here?
Systems default to minimal data collection and limited retention, with any wider sharing requiring an explicit opt-in rather than being on by default.
How is it confirmed that a new security control will not break a critical operational process?
Technical controls on production systems are designed and tested for interference with safety-critical functions before they go live.
Where regulation demands it
NIS2 Article 21 requires secure-by-design engineering as part of the secure development life cycle obligation (6.2).
ENS mp.sw.1 requires application development to build in security controls from design through acceptance, not bolt them on after launch.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.