Baseline requirements
The security program baseline
Baseline requirements for a security program. Every organization is different and some will need more or less, but each of these should be considered.
Take the self assessmentScore yourself against the list below. 12 questions for boards and executives, or all 54 for IT and security. Free, scored in your browser, and no data is uploaded.
T1
Baseline 36
Every organization at any size. Mostly cheap. Absence is a finding.
Every organization at any size. Mostly cheap. Absence is a finding.
T2
Standard 12
Once customers depend on you, or you hold regulated or sensitive data.
Once customers depend on you, or you hold regulated or sensitive data.
T3
Advanced 2
An operated program, with a security function or an MSSP behind it.
An operated program, with a security function or an MSSP behind it.
AI
If using AI 4
Applies when you build or deploy AI features.
Applies when you build or deploy AI features.
The AI rows are conditional rather than tiered. All of them apply if you build or deploy AI features. If you do not, only the vendor data retention line applies.
| Tier | Requirement | Ask |
|---|---|---|
| Security program | ||
| T1 | Security owner. A named person accountable for security, plus the security team roles and names. | Who owns security, and what would they spend the next dollar on? |
| T1 | Policy. A register of every policy with owner, published date and last reviewed date. | Which policy changed most recently, and what prompted it? |
| T2 | Risk register. Identified risks, each with an owner and a named person who accepted or mitigated it, reviewed on a cadence. | What are our top three open risks, and who accepted each one? |
| Inventoryeach item documented, with owner and review as necessary | ||
| T1 | External attack surface. Domains, subdomains, IPs, APIs, exposed services, forgotten assets. | Show me everything we expose to the internet, with an owner on each line. |
| T1 | Code. Every repo, and who can read/write. | |
| T1 | Cloud. Accounts, projects, subscriptions, user access. | |
| T1 | Endpoints. Laptops, servers, container hosts, mobile, contractor and BYOD. | |
| T1 | Data. Where sensitive data lives, and the defined classification tiers that govern how each is handled. | |
| T1 | SaaS and vendors. Inventory assets and user/admin access. | |
| T1 | AI. Models, agents, MCP servers, and the credentials each holds. | |
| T2 | Vendor risk. Security terms in the contract, a review before onboarding, access removed at offboarding. | |
| T2 | Data retention and disposal. How long each data class is kept and how it is destroyed, including devices and media. | |
| Identity, credentials and keys | ||
| T1 | Phishing-resistant MFA. Define what is allowed (FIDO2, passkeys, hardware keys) and what is explicitly not allowed (SMS, TOTP). | What share of our accounts use hardware keys or passkeys? |
| T1 | Least privilege on human and service accounts. Inventory and statement of least privilege. | |
| T1 | Separate admin accounts from daily-use accounts, and a break-glass procedure for when SSO is down. | |
| T1 | API key inventory; include owner, expiration and rotation policy. | How many API keys do we have, and how fast can we revoke one? |
| T1 | Secrets policy and testing approach. | |
| T1 | Revocation policy/approach. | |
| T1 | Access review and offboarding. Joiner, mover and leaver, covering contractors and service accounts. | Show me the last access review, and when it was done. |
| Endpoints and corporate IT | ||
| T1 | EDR on laptops, servers and other hosts, plus DNS or web filtering on user devices to block malicious and lookalike sites. | Show me EDR coverage measured against the full endpoint list. |
| T1 | Patching. OS, browsers, extensions and third-party apps. | |
| T1 | SSO auth requirements; is posture a condition for system access. | |
| T1 | SPF, DKIM and DMARC at enforcement, plus inbound filtering. | |
| T1 | Full-disk encryption on every endpoint, as a condition of access. | |
| T1 | Physical. Office and server-room access, device theft, screen locks. | |
| T2 | MDM on mobile, including the phone that holds the MFA factor. | |
| Infrastructure and configuration | ||
| T1 | Authenticated vulnerability scanning, internal and external, on a schedule. | |
| T1 | Patch SLAs by severity, priced in days rather than weeks. | What is our deadline to patch a critical flaw, in days, and do we meet it? |
| T1 | Admin interfaces off the public internet. | |
| T1 | Encryption of data at rest and in transit, with the keys managed somewhere other than the data. | |
| T2 | Continuous evaluation of cloud configuration, permissions, network exposure and secrets. | |
| T2 | Segmentation and egress control, so one compromised workload cannot reach the data store or ship data out quietly. | |
| Code and supply chain | ||
| T1 | SAST, software composition analysis, secrets detection and IaC scanning in CI. Full repository testing. | |
| T1 | Dependency provenance and pinning. | |
| T1 | Protected main branch, review required before merge, and pipeline configuration treated as privileged. | |
| T2 | Model-assisted review as an addition. Multiple models. | |
| T2 | An SBOM with a path from new CVE to affected deployed versions. | If a library we use were compromised today, how long until we know where it runs? |
| AI agent, chat, code tools | ||
| AI | Model and application behavior. Prompt injection, unsafe output handling, data disclosure, policy bypass, model vendor policy around data retention and training. | |
| AI | Tools and agents. Excessive agency, authorization boundaries, cross-user access, privilege escalation through connected tools. | |
| AI | MCP and integrations. Tool inventory, authentication and authorization policy. | |
| AI | Runtime. Sandboxing, high-impact tool calls monitored or human-looped, an audit trail. | Show me every AI agent and integration, and what each can access. |
| Adversarial validation | ||
| T1 | Defined process/tickets for identified vulnerabilities. | How old is our oldest open critical finding? |
| T2 | Keep periodic human-led testing. | When did someone outside last try to break in, and what did they find? |
| T3 | Continuous external attack surface discovery and automated adversarial testing using multiple models and exploitability validation. | |
| Detection, response and recovery | ||
| T1 | Cloud provider audit logs enabled on every account, plus authentication events and admin actions, forwarded centrally. | |
| T1 | IR plan, walked through once out loud. | When did we last run the incident plan, and what broke? |
| T1 | Notification obligations known in advance. Regulators, customers under contract, insurer, law enforcement, and the window for each. | If we were breached Friday night, who must we notify, and by when? |
| T1 | Backups process and testing. | When did we last restore from backup, and did it work? |
| T1 | Remediation SLA, testing, root cause, incident tracking. | |
| T2 | Centralized security telemetry, monitoring, SIEM, with a defined log retention period. | |
| T3 | 24/7 monitoring and alerting with a named owner outside business hours. | |
| The human and brand surface | ||
| T1 | Phishing and security awareness training; is the program AI-aware. | What does an employee do when asked to move money or reset access? |
| T2 | Monitor lookalike domains, cloned login pages & social accounts, impersonation accounts and leaked credentials. | |
| T2 | Pre-authorized takedown with a vendor holding power of attorney. | |
Take the self-assessment Download the one-page image Security services
We use this list to scope security programs and to find the gaps in one that already exists.