Security is a process, not a badge.
This page describes what we actually do — the control frameworks we align our practice to, how code gets reviewed before it ships, how we find and close vulnerabilities, and what happens at 3am when something breaks. If any of it matters to your procurement process, ask us for the detail behind it.
The control frameworks we work against.
- CIS Controls v8
- NIST Cybersecurity Framework
- ISO/IEC 27001 — Annex A
- SOC 2 — Trust Services Criteria
- OWASP Top 10
- OWASP ASVS
- Microsoft Cloud Security Benchmark
We use these as the checklist for design reviews, hardening baselines and remediation plans — not as marketing vocabulary. When a client is preparing for an audit, these are the control sets we map their environment against and the gaps we work to close.
What we are, and what we are not.
Certus ITM is not currently ISO 27001 or SOC 2 certified as an organization, and we are not an accredited audit firm. We align our own practice to these control sets, and we prepare and remediate client environments so they pass the audit their certifying body runs. Any vendor telling you otherwise about themselves is worth a second look at their certificate.
How code gets from a branch to production.
Every application we build — for a client or for our own products — moves through the same gates. The languages and runtimes we work in are listed under Operation; this is the process wrapped around them.
-
Threat modelling at design time
Before the first endpoint is written we map trust boundaries, data classification and the abuse cases that matter for that system. The security model is part of the architecture document you approve.
-
No direct pushes to main
Protected branches, pull requests, and review by a second engineer before merge. Nothing reaches a production branch on one person's judgement alone.
-
Automated scanning in the pipeline
Static analysis and dependency vulnerability scanning run on every pull request. A known-vulnerable transitive dependency fails the build rather than shipping quietly.
-
Secrets never live in the repository
Credentials, keys and connection strings are held in a managed vault — Password Manager Pro or the platform's native key store — and injected at deploy time. Repository history is scanned for leaked secrets.
-
Separated environments
Development, staging and production are isolated, with separate credentials and separate data. Production data is never copied into a lower environment without being masked first.
-
Least-privilege deployment identities
CI/CD runners authenticate with scoped, short-lived credentials that can deploy the one thing they are responsible for — not with a standing administrator account.
-
Auditable releases
Every deployment traces back to a commit, a reviewer and a ticket. When something regresses we can tell you exactly what changed, who approved it and when — and roll back to the previous version.
-
You own the code
Your repository, your cloud tenancy, your domains. Handover is a contractual right, not a negotiation — including the runbooks and the architecture decision records.
The controls we operate day to day.
These are the tooling and the routines behind the managed-services contract — the platforms our engineers hold hands-on experience with, grouped by the control they serve.
Vulnerability management
- Qualys
- CIS Controls baselines
- Scheduled scanning
- Remediation by severity
Identity & access
- Microsoft Entra ID
- Active Directory · ADFS
- Cisco DUO — MFA
- Role-based access
- Password Manager Pro
Endpoint & perimeter
- CrowdStrike — EDR
- Bitdefender
- Fortinet · Cisco — firewalls
- Barracuda — content filtering
Patch & configuration
- Microsoft Intune
- WSUS
- Group Policy · hardening baselines
- AD Manager · AD Audit
Backup & continuity
- Veeam
- ARCserve
- VMware SRM
- Dell RecoverPoint · AppSync
- Defined RPO / RTO
Monitoring & response
- PRTG
- VMware Aria Operations / Logs
- InvGate · ServiceDesk
- 24/7 on-call rotation
Incident response, written down before you need it.
Every managed client gets a severity matrix agreed at contract signing: what counts as critical, who gets called, in what order, and how long each step is allowed to take. Nobody improvises the escalation path at 3am.
-
Detect & triage
Monitoring alerts into the on-call rotation. Severity is assigned against the agreed matrix, not by whoever picks up.
-
Contain, then fix
Stop the bleeding first — isolate, revoke, fail over. Root cause comes after the business is running again.
-
Written post-mortem
Every critical incident produces a blameless write-up: timeline, root cause, and the specific change that stops it recurring. You get it, not just us.
-
Confidentiality holds
Incidents are covered by the same NDA as everything else. We do not disclose your incidents, and we do not use them as sales material.