Secure development (draft)
This page captures draft secure-development expectations that are commonly required for ISO 27001 readiness. It is written to be tool-agnostic and should be refined to match our actual delivery workflow.
When to use this page
Section titled “When to use this page”- Starting a new project or environment
- Changing access paths, authentication, or sensitive data flows
- Shipping code/config changes to production-like environments
Policy anchors
Section titled “Policy anchors”- Data handling: Information classification policy
- Access control: Access control policy
- Vulnerabilities: Vulnerability management procedure
- Incidents: Incident response procedure
Minimum expectations (draft)
Section titled “Minimum expectations (draft)”1) Change discipline
Section titled “1) Change discipline”- Changes are tracked (who/what/why/when).
- High-risk changes have an explicit reviewer/approver.
See Change management (draft).
2) Secrets and credentials
Section titled “2) Secrets and credentials”- Never commit secrets to Git.
- Store credentials only in approved systems (e.g., Vault, where applicable).
3) Least privilege by default
Section titled “3) Least privilege by default”- Access is granted based on role and task.
- Prefer SSO/MFA when supported by the target system.
4) Dependency and component hygiene
Section titled “4) Dependency and component hygiene”- Keep third-party dependencies and platform components updated within project constraints.
- Treat advisories as inputs to Vulnerability management.
5) Logging and auditability
Section titled “5) Logging and auditability”- Ensure actions affecting sensitive data can be audited where feasible.
Records / evidence
Section titled “Records / evidence”- Change records (PRs/tickets/releases):
- Review/approval evidence: