What an auditor, or Sekit's evidence engine, asks for.
Risk assessment and treatment plan
The record where the company identifies its security risks and decides what to do with each one (accept, reduce or transfer), with owners and deadlines.
Secure development policy
The rules the development team follows to build software securely: security requirements, code review and threat modeling.
From the Sekit evidence catalog
In practice
In practice, security in project management means a new system does not go live until it has been through a defined checklist: risk treatment items assigned, identity integration completed, and security requirements signed off before deployment. Auditors probe by picking a recent project and asking to trace it against the secure development policy step by step; the usual gap is a policy that reads well but skips a stage under deadline pressure, most often the risk treatment plan being backfilled after launch instead of before. Connecting new applications to the central identity system before go-live is one of the most commonly skipped steps under time pressure.
Common gaps
The risk assessment and treatment plan gets written after a project has already launched, turning it into documentation rather than a decision input.
New applications go live before being connected to the central identity provider, leaving a window of locally managed accounts nobody tracks.
The secure development policy exists but project managers cannot point to where in their own project plan its requirements were checked.
Questions your auditor will ask
Where in the project lifecycle does security get considered?
The secure development policy requires it from design through release, and the risk assessment and treatment plan shows risks assigned and treated before launch.
Is a new application connected to the identity provider before staff start using it?
Identity integration is a routine step in onboarding a new application, completed before deployment rather than retrofitted afterward.
Who approves the risk treatment plan for a new project before go-live?
A named owner in the risk assessment and treatment plan signs off before launch, with deadlines attached to each treatment item.
Where regulation demands it
NIS2 6.2 requires a secure development life cycle that builds security into each project stage, the core expectation of A.5.8.
ENS mp.sw.2 covers acceptance and go-live, the checkpoint where a project's security requirements must be verified before deployment.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.