SIMPLIFIEDCS · NIST CSF 2.0 · CIS Controls v8.1
Example A fictional organization and fictional answers, run through the real scoring engine - not a real assessment.
Example report

IT services firm

A fictional 40-person IT services and software consultancy: hybrid estate, security monitoring partly outsourced, SOC 2 in scope.

Full assessment

Critical gaps found

1 critical control is not in place. Fix it first - the percentage alone understates the risk.

Coverage
54%
Completeness
48 of 48
Critical gaps
1
Not sure
0

Coverage is not a compliance score, and 100% doesn't mean risk-free. How this is scored

Critical gaps (1) - fix these first

Access & Identity: MFA covers admin accounts only, and you have internet-reachable services (cloud or remote access), so ordinary accounts can be taken over with a password alone. Your answer: "Admin accounts only"

Coverage by area

Your Team & Vendors
38%
7 of 7 answered
Data & Systems
33%
2 of 2 answered
Access & Identity
56%
27 of 27 answered
Detection & Monitoring
55%
6 of 6 answered
Incident Readiness
60%
3 of 3 answered
Recovery & Continuity
56%
3 of 3 answered

Action plan - 39 actions, ranked by risk

Every gap, "Not sure" and finding in this report, ranked by how much it matters: how critical the control is, how far from in place it is, and whether it feeds a combined finding. Each says why it ranks where it does. Target timeframes are suggestions: 30 days for critical items and anything to confirm, 60 for high-impact, 90 for the rest.

Within 30 days 4 actions

01

Access & Identity · Is multi-factor authentication enforced for remote and admin access? - your answer: "Admin accounts only"
Critical gap Effort: Low Target: 30 days
  • Why it's critical: MFA covers admin accounts only, and you have internet-reachable services (cloud or remote access), so ordinary accounts can be taken over with a password alone.
  • Why it ranks here: Your answer: "Admin accounts only" · Critical control (CISA Performance Goals / #StopRansomware priority) · MFA covers admin accounts only, and you have internet-reachable services (cloud or remote access), so ordinary accounts can be taken over with a password alone.
  • What could go wrong: MFA is the specific control that stops a leaked or guessed password alone from being enough to log in as a legitimate user.
  • Attack technique: MITRE ATT&CK T1078 - Valid Accounts
  • Interim step: Prioritize MFA on admin and remote-access accounts first - that's the smallest rollout that closes the largest share of risk.
  • Durable fix: Enforce MFA for every account, not just admins - most identity providers (Microsoft Entra, Google Workspace, Okta) support org-wide enforcement from one setting.
  • Suggested owner: IT lead
  • Evidence it's done: Identity-provider report showing MFA enforced for all users and admin roles
  • Framework references: NIST CSF 2.0: PR.AA-03 · CIS Controls v8.1: 6.3, 6.4, 6.5
  • Reference: CISA: Require Multifactor Authentication
04

Access & Identity · How are software patches and updates managed? - your answer: "Scheduled but inconsistent"
Critical control Effort: Medium Target: 30 days
  • Why it ranks here: Your answer: "Scheduled but inconsistent" · Critical control (CISA Performance Goals / #StopRansomware priority)
  • What could go wrong: Unpatched software is what turns an already-known, already-fixed vulnerability into a working exploit - attackers routinely scan for exactly this rather than looking for something novel.
  • Attack technique: MITRE ATT&CK T1190 - Exploit Public-Facing Application
  • Interim step: Vulnerability scanning is happening at least occasionally, which helps surface what's missing - use that output to prioritize patching your internet-facing systems first, ahead of everything else.
  • Durable fix: Automate patch deployment with a defined SLA (e.g. critical patches within 72 hours, everything else within 30 days) rather than ad hoc manual patching.
  • Suggested owner: IT lead
  • Evidence it's done: Patch-compliance report and the written patching timeframes
  • Framework references: NIST CSF 2.0: PR.PS-02 · CIS Controls v8.1: 7.3, 7.4, 7.7
06

Access & Identity · How are privileged accounts (domain admins, database admins, local/server administrators) managed? - your answer: "Individually assigned, but not regularly reviewed"
Critical control Effort: Medium Target: 30 days
  • Why it ranks here: Your answer: "Individually assigned, but not regularly reviewed" · Critical control (CISA Performance Goals / #StopRansomware priority)
  • What could go wrong: Shared or long-standing privileged credentials are a high-value target precisely because they're rarely rotated and often outlive the reason they were created - one compromise can go unnoticed for a long time.
  • Attack technique: MITRE ATT&CK T1078 - Valid Accounts
  • Interim step: As an interim step, do a one-time manual review of who currently holds privileged access and revoke anything clearly stale - a single pass now is better than waiting for a full recurring review process.
  • Durable fix: Individually assign every privileged account (no shared logins), and schedule a recurring (at least quarterly) access review with least-privilege enforcement.
  • Suggested owner: IT lead
  • Evidence it's done: Privileged account inventory with owners and last review/rotation dates
  • Framework references: NIST CSF 2.0: PR.AA-01, PR.AA-05 · CIS Controls v8.1: 5.1, 5.2, 5.4
07

Recovery & Continuity · How often are backups tested by actually restoring data? - your answer: "Rarely"
Critical control Effort: Low Target: 30 days
  • Why it ranks here: Your answer: "Rarely" · Critical control (CISA Performance Goals / #StopRansomware priority)
  • What could go wrong: This is the ransomware technique - and an untested backup is a backup whose recoverability is simply unknown until the day it matters most.
  • Attack technique: MITRE ATT&CK T1486 - Data Encrypted for Impact
  • Interim step: Backups are at least isolated from the production network, which is the part that matters most against ransomware specifically - test-restore a single file or system now for a first real data point.
  • Durable fix: Schedule quarterly (at minimum) backup-restore tests against real systems, documenting actual restore time against your required recovery targets.
  • Suggested owner: IT lead
  • Evidence it's done: Restore test log with dates, systems restored and time taken
  • Framework references: NIST CSF 2.0: PR.DS-11, RC.RP-03 · CIS Controls v8.1: 11.5
  • Reference: CISA: StopRansomware

Within 60 days 16 actions

02

Detection & Monitoring · Do you monitor for data exfiltration or unusual outbound traffic? - your answer: "No"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "No" · High-impact control · Part of 1 combined finding below
  • What could go wrong: Without monitoring for unusual outbound traffic, this is how a breach goes from "contained" to "data actually left the building" without anyone noticing at the time.
  • Attack technique: MITRE ATT&CK T1041 - Exfiltration Over C2 Channel
  • Interim step: Centralized logging exists - as an interim step, add a basic alert for large or unusual outbound data transfers using what's already being collected, rather than waiting on a dedicated exfiltration-monitoring tool.
  • Durable fix: Enable outbound traffic monitoring with alerting on unusually large or unusual-destination transfers - most modern firewalls and cloud platforms support this as a built-in feature.
  • Suggested owner: Security lead
  • Evidence it's done: Outbound traffic or DLP alert configuration
  • Framework references: NIST CSF 2.0: DE.CM-01 · CIS Controls v8.1: 3.13, 13.6
03

Recovery & Continuity · Do you have a documented business continuity / disaster recovery plan? - your answer: "No"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "No" · High-impact control
  • What could go wrong: Without a documented business continuity/disaster recovery plan, an outage forces improvised decisions about which systems and processes matter most to restore first - decided for the first time during the outage itself.
  • Interim step: As an interim step, list your top 3-5 business-critical systems and their rough acceptable downtime, even before a full BCDR plan exists.
  • Durable fix: Document a business continuity/disaster recovery plan defining recovery priorities, targets (RTO/RPO), and alternate processes, and test it periodically.
  • Suggested owner: Leadership
  • Evidence it's done: Plan document with recovery priorities and last review date
  • Framework references: NIST CSF 2.0: ID.IM-04, RC.RP-01 · CIS Controls v8.1: 11.1
08

Your Team & Vendors · Are third parties with access to your systems or data (IT providers, SaaS vendors, contractors) reviewed for security before they get access, and periodically after? - your answer: "Informally, or only when they're first onboarded"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "Informally, or only when they're first onboarded" · High-impact control
  • What could go wrong: Third parties with access to your systems or data are a way in that doesn't require attacking you directly - a compromised IT provider or SaaS vendor account is used as a trusted path into your environment.
  • Attack technique: MITRE ATT&CK T1199 - Trusted Relationship
  • Interim step: Use your existing asset inventory to identify which vendors touch your most sensitive systems or data, and review just that short list manually as an interim step.
  • Durable fix: Build a vendor inventory recording what each vendor can access, and require a lightweight security review before granting any new vendor access going forward.
  • Suggested owner: Security lead
  • Evidence it's done: Vendor inventory with access scope, last review date and outcome
  • Framework references: NIST CSF 2.0: GV.SC-04, GV.SC-07 · CIS Controls v8.1: 15.1, 15.5, 15.6
11

Data & Systems · How would you describe your asset inventory? - your answer: "Partial, manually maintained spreadsheet"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "Partial, manually maintained spreadsheet" · High-impact control
  • What could go wrong: Without a real asset inventory, you can't protect what you don't know exists - shadow IT and forgotten systems are common actual entry points precisely because nobody is watching them.
  • Interim step: Do a manual one-time inventory pass this month of anything with an IP address or a login, even without ongoing automation yet.
  • Durable fix: Deploy automated asset discovery (many EDR and network tools include this) and review the inventory at least quarterly.
  • Suggested owner: IT lead
  • Evidence it's done: Inventory export with last-updated date covering devices, servers and cloud services
  • Framework references: NIST CSF 2.0: ID.AM-01, ID.AM-02 · CIS Controls v8.1: 1.1, 1.3, 2.1
14

Access & Identity · Does routine application access to that database use least-privilege, application-specific credentials - not a shared or admin/root account? - your answer: "Partially - some services still use shared/admin credentials"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "Partially - some services still use shared/admin credentials" · High-impact control
  • What could go wrong: Routine application access through a shared or admin database credential means a single compromised credential (from the app server, a leaked config file, or a former employee) grants broad, often unaudited access to the entire database.
  • Attack technique: MITRE ATT&CK T1078 - Valid Accounts
  • Interim step: As an interim step, restrict the current shared/admin credential to only the specific tables or operations the application actually needs.
  • Durable fix: Provision a dedicated, least-privilege application account scoped to only what the app requires, and retire the shared/admin credential from routine use.
  • Suggested owner: Developers
  • Evidence it's done: List of application database accounts and their granted permissions
  • Framework references: NIST CSF 2.0: PR.AA-05 · CIS Controls v8.1: 3.3, 5.4
  • OWASP Top 10: A01:2021 - Broken Access Control, with the matching Playbook
15

Access & Identity · Is the database software itself (not just the application) kept current and patched? - your answer: "Patched, but inconsistently or behind schedule"
High impact Effort: Low Target: 60 days
  • Why it ranks here: Your answer: "Patched, but inconsistently or behind schedule" · High-impact control
  • What could go wrong: Database software carries its own CVEs independent of the application built on top of it - an unpatched database engine can be exploited directly, bypassing whatever protections exist at the application layer entirely.
  • Attack technique: MITRE ATT&CK T1190 - Exploit Public-Facing Application
  • Interim step: As an interim step, check your database engine's current version against its vendor's security advisories to see if any known-exploited vulnerability applies right now.
  • Durable fix: Put database software on the same defined patch cadence as the rest of your infrastructure - most managed cloud database services offer automatic minor-version patching as a configuration option.
  • Suggested owner: IT lead
  • Evidence it's done: Database version report against the vendor's supported versions
  • Framework references: NIST CSF 2.0: PR.PS-02 · CIS Controls v8.1: 7.4
  • OWASP Top 10: A06:2021 - Vulnerable and Outdated Components, with the matching Playbook
16

Access & Identity · Do employees receive security awareness training? - your answer: "Once, at onboarding"
High impact Effort: Low Target: 60 days
  • Why it ranks here: Your answer: "Once, at onboarding" · High-impact control
  • What could go wrong: Training is the human-side defense against this technique - recognizing and reporting a malicious link or attachment before it's acted on.
  • Attack technique: MITRE ATT&CK T1566 - Phishing
  • Interim step: As an immediate step, publish a simple, well-known way for employees to report suspicious email - low-effort, and useful even before formal training exists.
  • Durable fix: Stand up recurring (not one-time) security awareness training - even a low-cost platform with monthly micro-training beats an annual slideshow.
  • Suggested owner: Security lead
  • Evidence it's done: Training completion records for the last 12 months
  • Framework references: NIST CSF 2.0: PR.AT-01 · CIS Controls v8.1: 14.1, 14.2
18

Access & Identity · Is email authentication (SPF, DKIM, and DMARC set to quarantine/reject) enforced for your domain? - your answer: "Partially - e.g. DMARC set to "none""
High impact Effort: Low Target: 60 days
  • Why it ranks here: Your answer: "Partially - e.g. DMARC set to "none"" · High-impact control
  • What could go wrong: Without SPF/DKIM/DMARC enforced, attackers can send mail that appears to come from your own domain, to your own employees, customers, or partners.
  • Attack technique: MITRE ATT&CK T1566 - Phishing
  • Interim step: As a fast interim step, start DMARC at p=none with aggregate (RUA) reports on - it stays non-blocking while it reveals every source sending as your domain, which is what you need before enforcing.
  • Durable fix: Publish SPF and DKIM records, then enforce DMARC in stages - p=none with aggregate reports to inventory senders and fix SPF/DKIM alignment (third-party senders included), then quarantine, then reject - monitoring the reports and keeping a rollback ready at each step, since misaligned legitimate mail is quarantined until its alignment is corrected.
  • Suggested owner: IT lead
  • Evidence it's done: DNS records and DMARC policy set to quarantine or reject
  • Framework references: CIS Controls v8.1: 9.5
19

Access & Identity · Are administrative accounts kept separate from everyday user accounts? - your answer: "Partially"
High impact Effort: Low Target: 60 days
  • Why it ranks here: Your answer: "Partially" · High-impact control
  • What could go wrong: When the same account is used for everyday work and admin tasks, there's no privilege escalation for an attacker to perform - a single compromised login is already an admin login.
  • Attack technique: MITRE ATT&CK T1078 - Valid Accounts
  • Interim step: As an interim step short of full separation, at minimum create a distinct admin login for the highest-risk systems (domain controllers, core financial or customer data) first, rather than everywhere at once.
  • Durable fix: Issue separate admin and everyday accounts for every user who needs elevated access, with the admin account never used for email, browsing, or routine work.
  • Suggested owner: IT lead
  • Evidence it's done: List of admin accounts, each distinct from the owner's daily account
  • Framework references: NIST CSF 2.0: PR.AA-05 · CIS Controls v8.1: 5.4
21

Access & Identity · Is there a formal process to revoke all access immediately when someone leaves or changes roles? - your answer: "Informal / inconsistent"
High impact Effort: Low Target: 60 days
  • Why it ranks here: Your answer: "Informal / inconsistent" · High-impact control
  • What could go wrong: An account left active after someone leaves is a fully legitimate-looking login that nobody is watching - one of the most common, least sophisticated ways attackers (including former employees) get in.
  • Attack technique: MITRE ATT&CK T1078 - Valid Accounts
  • Interim step: Centralized logging is in place - use it to set an alert specifically for logins from accounts belonging to recently departed staff as an interim measure until offboarding is fully automated.
  • Durable fix: Automate access revocation tied to HR's own termination workflow (most identity providers support this integration) so it doesn't depend on someone remembering a manual step.
  • Suggested owner: HR / IT lead
  • Evidence it's done: Offboarding checklist and recent leaver tickets with access-removal times
  • Framework references: NIST CSF 2.0: PR.AA-01, PR.AA-05 · CIS Controls v8.1: 5.3, 6.2
23

Access & Identity · For payment changes or other sensitive requests, is there an authenticated, out-of-band verification step that would still hold up even if email, voice, and video were all convincingly impersonated? - your answer: "Some verification exists, but not out-of-band or not consistently applied"
High impact Effort: Low Target: 60 days
  • Why it ranks here: Your answer: "Some verification exists, but not out-of-band or not consistently applied" · High-impact control
  • What could go wrong: If a convincing voice or video impersonation is all it takes to authorize a payment change or a sensitive request, training alone won't reliably stop it - an out-of-band verification step is the control that holds even when every other channel is successfully spoofed.
  • Attack technique: MITRE ATT&CK T1566.004 - Phishing: Spearphishing Voice
  • Interim step: As an interim step, require any payment-change request to be confirmed by a callback to a phone number already on file (never a number provided in the request itself), even before a formal out-of-band process is documented.
  • Durable fix: Define and enforce an authenticated, out-of-band verification step (a callback to a known number, or in-person confirmation) for payment changes and other sensitive requests, documented as a required step regardless of how convincing the original request appeared.
  • Suggested owner: Finance lead
  • Evidence it's done: Written verification procedure and examples of it being applied
  • Reference: MITRE ATT&CK: Phishing: Spearphishing Voice (T1566.004)
24

Detection & Monitoring · Do you run regular external and internal vulnerability scans? - your answer: "Occasionally / ad hoc"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "Occasionally / ad hoc" · High-impact control
  • What could go wrong: Without regular vulnerability scanning, known exploitable flaws in your own systems go undiscovered by you - and get discovered by an attacker's scan instead.
  • Attack technique: MITRE ATT&CK T1190 - Exploit Public-Facing Application
  • Interim step: As an interim step, run a single one-time scan against your internet-facing systems now (several reputable free/low-cost scanners exist) even before a recurring schedule is set up.
  • Durable fix: Schedule regular (at minimum quarterly, ideally continuous) external and internal vulnerability scans, and track findings to remediation.
  • Suggested owner: IT lead
  • Evidence it's done: Scan schedule and recent scan reports
  • Framework references: NIST CSF 2.0: ID.RA-01 · CIS Controls v8.1: 7.5, 7.6
26

Incident Readiness · Do you have a documented incident response plan? - your answer: "Yes, but never tested"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "Yes, but never tested" · High-impact control
  • What could go wrong: An untested (or absent) incident response plan means the first real incident becomes the first rehearsal - improvised decisions under pressure are slower and more error-prone than a practiced process.
  • Interim step: As an interim step, write a one-page "first hour" checklist (who declares an incident, who has authority to isolate a system) even before a full plan exists.
  • Durable fix: Write a documented incident response plan and test it annually via a tabletop exercise, updating it based on what the exercise reveals.
  • Suggested owner: Security lead
  • Evidence it's done: Plan document and the date/outcome of the last exercise
  • Framework references: NIST CSF 2.0: ID.IM-04, RS.MA-01 · CIS Controls v8.1: 17.4, 17.7
28

Access & Identity · How are secrets (API keys, credentials) managed in your applications/pipelines? - your answer: "Environment variables, informally managed"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "Environment variables, informally managed" · High-impact control
  • What could go wrong: Secrets in code or config files are readable by anyone with access to the repository, a build log or an artifact - and they stay valid long after they are forgotten.
  • Attack technique: MITRE ATT&CK T1552.001 - Unsecured Credentials: Credentials In Files
  • Interim step: Rotate any credential that has ever been committed to a repository, and turn on secret scanning so new ones are caught.
  • Durable fix: Move application secrets into a secrets manager (cloud providers include one), load them at runtime, and block commits that contain secrets.
  • Suggested owner: Developers
  • Evidence it's done: Secrets manager in use; secret-scanning results showing no secrets in repositories
  • Framework references: NIST CSF 2.0: PR.PS-06
29

Access & Identity · How are hypervisor hosts patched and maintained? - your answer: "Scheduled maintenance windows"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "Scheduled maintenance windows" · High-impact control
  • What could go wrong: Ransomware groups specifically target hypervisors: one compromised host can encrypt every virtual machine it runs at once.
  • Attack technique: MITRE ATT&CK T1210 - Exploitation of Remote Services
  • Interim step: Make sure hypervisor management interfaces are not reachable from user networks or the internet, and apply the vendor's latest security patches.
  • Durable fix: Patch hypervisor hosts on a defined schedule with an SLA for critical fixes, and keep management interfaces on an isolated admin network.
  • Suggested owner: IT lead
  • Evidence it's done: Hypervisor version report and patch schedule
  • Framework references: NIST CSF 2.0: PR.PS-02 · CIS Controls v8.1: 7.3
30

Access & Identity · Are VMs/containers for different trust levels (e.g. production vs. test, internet-facing vs. internal) network-segmented from each other? - your answer: "Partially segmented"
High impact Effort: Medium Target: 60 days
  • Why it ranks here: Your answer: "Partially segmented" · High-impact control
  • What could go wrong: When internet-facing, production and test workloads share a network, a compromise of the weakest one - often a test system - gives a route to the rest.
  • Attack technique: MITRE ATT&CK T1021 - Remote Services
  • Interim step: Restrict inbound access to production and internal workloads to the specific sources that need it, starting with internet-facing systems.
  • Durable fix: Separate workloads by trust level with network rules or security groups, and allow only the connections each one requires.
  • Suggested owner: IT lead
  • Evidence it's done: Network or security-group rules separating production, test and internet-facing workloads
  • Framework references: NIST CSF 2.0: PR.IR-01 · CIS Controls v8.1: 12.2, 16.8

Within 90 days 19 actions

05

Access & Identity · Do you run simulated phishing tests for employees? - your answer: "No"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "No" · Part of 1 combined finding below
  • What could go wrong: Simulated phishing tests are how you find out whether your actual defenses against this technique - training, filtering, reporting habits - are working, rather than assuming they are.
  • Attack technique: MITRE ATT&CK T1566 - Phishing
  • Interim step: Run one low-stakes manual test before investing in a platform - a single internal email from IT with a fake link, tracking who clicks. It's a real data point at effectively no cost.
  • Durable fix: Add recurring simulated phishing tests (monthly or quarterly) and track click/report rates over time as the real measure of whether training works.
  • Suggested owner: Security lead
  • Evidence it's done: Simulation results over time (click and report rates)
  • Framework references: NIST CSF 2.0: PR.AT-01 · CIS Controls v8.1: 14.2
09

Your Team & Vendors · Is the organization's use of AI tools tracked and governed? - your answer: "Used with no tracking or policy"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "Used with no tracking or policy"
  • What could go wrong: Ungoverned AI tool usage commonly means sensitive data gets pasted into third-party AI services with unclear data-retention/training terms, or unreviewed AI-generated code ships without the same scrutiny other code gets.
  • Interim step: Publish a one-page "don't paste this into AI tools" list (customer data, credentials, source code) immediately, before a formal policy exists.
  • Durable fix: Establish a formal AI usage policy naming approved tools, prohibited data categories, and track usage the same way other software is inventoried.
  • Suggested owner: Security lead
  • Evidence it's done: AI usage policy and an inventory of approved AI tools
  • Framework references: NIST CSF 2.0: GV.PO-01, ID.AM-02 · CIS Controls v8.1: 2.1
10

Your Team & Vendors · Is there a named, accountable owner for AI-related risk in your organization (even informally), and does your incident response plan address at least one AI-specific scenario (e.g. sensitive data pasted into a public AI tool, an AI-generated attack)? - your answer: "No named owner and no AI-specific IR scenario"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "No named owner and no AI-specific IR scenario"
  • What could go wrong: Not a specific attacker technique - a structural gap, the same shape as the other governance/ownership questions in this report. Every AI-specific finding elsewhere assumes someone is positioned to act on it; without a named owner or an incident response plan that even considers an AI-specific scenario, that assumption doesn't hold.
  • Interim step: Name one person as the informal point of contact for AI-related risk today, even without a documented mandate yet, and add one sentence to your incident response plan (or a scratch doc, if no formal plan exists) naming at least one AI-specific scenario to consider.
  • Durable fix: Formally name an accountable owner for AI-related risk (this can be an existing security/governance role, not necessarily a new hire) and extend your incident response plan to explicitly cover at least one AI-specific scenario, such as sensitive data pasted into a public AI tool or an AI-generated social-engineering attempt.
  • Suggested owner: Leadership
  • Evidence it's done: Named owner in writing; IR plan section covering an AI-specific scenario
  • Framework references: NIST CSF 2.0: GV.RR-02, ID.IM-04
12

Data & Systems · Do you classify data by sensitivity (public / internal / confidential / restricted)? - your answer: "No"
Standard Effort: Medium Target: 90 days
  • Why it ranks here: Your answer: "No"
  • What could go wrong: Without classifying data by sensitivity, every system gets roughly the same level of protection - your most sensitive data isn't specially guarded, and everything else isn't handled more cheaply either.
  • Interim step: Identify just your single most sensitive data category (e.g. customer PII, financial records) and apply extra access restriction to it now.
  • Durable fix: Define a simple 3-4 tier classification scheme (e.g. public/internal/confidential/restricted) and label major data stores/systems accordingly.
  • Suggested owner: Security lead
  • Evidence it's done: Classification scheme and labels applied to major data stores
  • Framework references: NIST CSF 2.0: ID.AM-05, ID.AM-07 · CIS Controls v8.1: 3.7
13

Access & Identity · Does your organization support passkeys or other passwordless authentication methods (e.g. WebAuthn/FIDO2, platform biometrics), in addition to or instead of passwords? - your answer: "No - passwords (with or without a separate MFA step) are the only option"
Standard Effort: Medium Target: 90 days
  • Why it ranks here: Your answer: "No - passwords (with or without a separate MFA step) are the only option"
  • What could go wrong: Even with MFA, a password can still be phished, reused, or brute-forced as the first factor. Passkeys remove that weakness structurally - there's no shared secret for an attacker to ever obtain in the first place, since the private key never leaves the device.
  • Attack technique: MITRE ATT&CK T1110 - Brute Force
  • Interim step: If passkeys aren't feasible organization-wide yet, ensure MFA is at minimum fully enforced as the interim mitigation for the same underlying credential-theft risk.
  • Durable fix: Enable passkey/WebAuthn support in your identity provider (Microsoft Entra, Google Workspace, and Okta all support this natively) starting with admin and highest-risk accounts, then expand.
  • Suggested owner: IT lead
  • Evidence it's done: Identity-provider settings showing passkeys enabled, with adoption numbers
  • Framework references: NIST CSF 2.0: PR.AA-03
  • Reference: Microsoft Entra: passkey (FIDO2) authentication
17

Access & Identity · What is the actual cadence of that security awareness training? - your answer: "Ad hoc / no fixed schedule"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "Ad hoc / no fixed schedule"
  • What could go wrong: A single onboarding session is well-documented to fade from memory within months - without an ongoing cadence, the workforce's actual readiness against phishing decays continuously between now and whenever the next session happens to occur.
  • Attack technique: MITRE ATT&CK T1566 - Phishing
  • Interim step: Send one short refresher (even a single email with 2-3 real examples of recent phishing attempts) now, as an interim measure ahead of a fixed cadence.
  • Durable fix: Move to ongoing, recurring training (monthly micro-training beats an annual session) - most awareness platforms support this on autopilot once configured.
  • Suggested owner: Security lead
  • Evidence it's done: Training calendar and completion records
  • Framework references: NIST CSF 2.0: PR.AT-01 · CIS Controls v8.1: 14.1
20

Access & Identity · For those separate admin accounts, is elevated access always-on (standing privileges) or granted just-in-time for specific tasks? - your answer: "Standing / always-on elevated access"
Standard Effort: Medium Target: 90 days
  • Why it ranks here: Your answer: "Standing / always-on elevated access"
  • What could go wrong: Standing (always-on) elevated access means a compromised admin credential grants full privileges at any moment, indefinitely - just-in-time access limits the actual window an attacker has to a specific, short-lived, auditable elevation event.
  • Attack technique: MITRE ATT&CK T1078 - Valid Accounts
  • Interim step: As an interim step, review which standing-admin accounts are actually used daily versus rarely, and de-escalate the rarely-used ones to on-demand access first.
  • Durable fix: Adopt a privileged access management (PAM) solution or your identity provider's built-in just-in-time elevation feature (Microsoft Entra PIM, for example) so elevated access is granted per-task and expires automatically.
  • Suggested owner: IT lead
  • Evidence it's done: Privileged-access tool or process records showing time-bound elevation
  • Framework references: NIST CSF 2.0: PR.AA-05
22

Access & Identity · Has security awareness training been updated to address AI-generated phishing and voice/video impersonation specifically, not just traditional phishing? - your answer: "No - training doesn't address AI-generated phishing or impersonation specifically"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "No - training doesn't address AI-generated phishing or impersonation specifically"
  • What could go wrong: Generative AI has made convincing voice and video impersonation cheap and fast to produce - training that only covers traditional email phishing leaves employees unprepared for a call or video message that sounds and looks like a real, trusted person.
  • Attack technique: MITRE ATT&CK T1566.004 - Phishing: Spearphishing Voice
  • Interim step: As an interim step, send one short briefing to employees now describing what an AI-generated voice/video impersonation attempt looks like, even before it's folded into a formal training update.
  • Durable fix: Update security awareness training to explicitly cover AI-generated phishing and voice/video impersonation, including at least one realistic example, alongside the existing traditional-phishing content.
  • Suggested owner: Security lead
  • Evidence it's done: Training module covering AI-generated phishing and voice/video impersonation
  • Framework references: NIST CSF 2.0: PR.AT-01 · CIS Controls v8.1: 14.2
  • Reference: MITRE ATT&CK: Phishing: Spearphishing Voice (T1566.004)
25

Detection & Monitoring · Have you had an external penetration test or red-team engagement in the last 12 months? - your answer: "No"
Standard Effort: Medium Target: 90 days
  • Why it ranks here: Your answer: "No"
  • What could go wrong: A scan finds known vulnerabilities; a penetration test finds exploitable chains and logic flaws a scanner can't - going 12+ months without one means your actual exploitability (not just your patch level) is untested.
  • Interim step: As an interim step, at minimum ensure vulnerability scanning (a lighter-weight alternative) is happening regularly while a full pentest is scheduled.
  • Durable fix: Schedule an external penetration test or red-team engagement at least annually, and after any major infrastructure change.
  • Suggested owner: Security lead
  • Evidence it's done: Penetration test report dated within the last 12 months
  • Framework references: NIST CSF 2.0: ID.IM-02 · CIS Controls v8.1: 18.1, 18.2
27

Incident Readiness · Do you have a breach communication plan (legal, customers, regulators)? - your answer: "No"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "No"
  • What could go wrong: Without a breach communication plan, legal, customer, and regulatory notifications get improvised during the highest-pressure moment of an incident - increasing the odds of missed legal deadlines or reputational mistakes.
  • Interim step: As an interim step, identify who (legal counsel, a PR contact) would need to be looped in for a breach, even before a written plan exists.
  • Durable fix: Document a breach communication plan naming who notifies legal, customers, and regulators, and under what circumstances/timelines each applies.
  • Suggested owner: Leadership
  • Evidence it's done: Communication plan with contact lists for legal, customers and regulators
  • Framework references: NIST CSF 2.0: RS.CO-02, RS.CO-03 · CIS Controls v8.1: 17.2, 17.6
31

Your Team & Vendors · Is there a documented cybersecurity policy, approved by leadership? - your answer: "Yes, but outdated or unreviewed"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "Yes, but outdated or unreviewed"
  • What could go wrong: No leadership-approved policy means no top-down mandate driving readiness - controls depend on individual initiative rather than an accountable program, and are the first thing to lapse when the person who set them up leaves.
  • Interim step: Name one accountable owner for security decisions today, even informally, while a real policy gets drafted.
  • Durable fix: Draft a short (1-2 page) policy covering scope, acceptable use, and access basics, and get explicit leadership sign-off - a real, if brief, policy beats a comprehensive one that never gets approved.
  • Suggested owner: Leadership
  • Evidence it's done: Policy document with approval date and next review date
  • Framework references: NIST CSF 2.0: GV.PO-01, GV.PO-02
32

Your Team & Vendors · Are cybersecurity roles and responsibilities formally assigned? - your answer: "Somewhat, but not documented"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "Somewhat, but not documented"
  • What could go wrong: "IT handles it" as the entire answer means no one is specifically accountable for verifying any given control actually works - gaps surface only after an incident, not before one.
  • Interim step: Assign at least one named owner per major control area (endpoint, backups, access, monitoring, incident response) informally, today.
  • Durable fix: Document a simple RACI for your top control areas and review/update it at least annually or after any org change.
  • Suggested owner: Leadership
  • Evidence it's done: Written list (RACI) of security responsibilities and their owners
  • Framework references: NIST CSF 2.0: GV.RR-02
33

Your Team & Vendors · Does leadership receive regular reporting on cybersecurity risk? - your answer: "Ad hoc, when something goes wrong"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "Ad hoc, when something goes wrong"
  • What could go wrong: Leadership can't fund or prioritize what they don't know about - without regular reporting, resourcing decisions happen blind to actual risk.
  • Interim step: Send leadership a short informal summary of this assessment's findings now, even without a recurring cadence yet.
  • Durable fix: Establish at least a quarterly risk report to leadership covering top findings and progress against them.
  • Suggested owner: Security lead
  • Evidence it's done: Dated leadership reports or meeting minutes covering security risk
  • Framework references: NIST CSF 2.0: GV.OV-01, GV.OV-03
34

Your Team & Vendors · Is cybersecurity risk factored into business decisions (new vendors, new products) before they're approved? - your answer: "Sometimes, informally"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "Sometimes, informally"
  • What could go wrong: New vendors and products are onboarded without a security review, meaning risk enters the environment through decisions nobody security-vetted before signing.
  • Attack technique: MITRE ATT&CK T1195 - Supply Chain Compromise
  • Interim step: Informally require a quick IT/security check before any new vendor gets system or data access, even without a formal process yet.
  • Durable fix: Add a short vendor security questionnaire as a required step before contract signature for any new vendor touching systems or data.
  • Suggested owner: Leadership
  • Evidence it's done: Approval checklist showing the security review step, with recent examples
  • Framework references: NIST CSF 2.0: GV.RM-03, GV.SC-06 · CIS Controls v8.1: 15.5
35

Access & Identity · What is the organization's password policy for length, screening, and rotation? - your answer: "Basic rules enforced (e.g. a minimum length or complexity requirements)"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "Basic rules enforced (e.g. a minimum length or complexity requirements)"
  • What could go wrong: Weak or default password requirements make automated password-guessing and credential-stuffing attacks meaningfully more likely to succeed.
  • Attack technique: MITRE ATT&CK T1110 - Brute Force
  • Interim step: MFA is at least partially enforced, which limits what a guessed password alone can do - as an interim step, set a minimum length requirement (length matters more than complexity rules) even before a full policy is formalized.
  • Durable fix: Adopt a length-based password policy aligned with NIST SP 800-63B-4: require at least 15 characters where the password is the only factor (8 or more is acceptable when it is paired with MFA), screen new passwords against known-compromised and common-password lists, and drop forced periodic rotation and character-composition rules - both push people toward weaker, reused patterns. Keep this about human passwords; machine and service secrets are managed separately. Pair it with MFA.
  • Suggested owner: IT lead
  • Evidence it's done: Identity-provider password settings
  • Framework references: NIST CSF 2.0: PR.AA-01 · CIS Controls v8.1: 5.2
  • Reference: NIST SP 800-63B-4: Digital Identity Guidelines - Authentication and Authenticator Management
36

Access & Identity · Do you have documented change management controls for production systems? - your answer: "Informal"
Standard Effort: Medium Target: 90 days
  • Why it ranks here: Your answer: "Informal"
  • What could go wrong: Without documented change management, a SOC 2 Type II audit has no evidence trail to test - and more practically, undocumented production changes are a common source of accidental outages and unreviewed security-relevant misconfigurations alike.
  • Interim step: As an interim step, start logging production changes in a shared doc or ticketing system, even without formal approval gates yet.
  • Durable fix: Implement a change management process with required approval and logging for production changes - most ticketing/CI tools (Jira, GitHub, ServiceNow) support this as a workflow, not a separate system.
  • Suggested owner: IT lead
  • Evidence it's done: Change records with approvals for recent production changes
  • Framework references: NIST CSF 2.0: PR.PS-01, ID.RA-07
37

Access & Identity · Is AI-generated code or AI tool output reviewed the same way human-written code is, before being merged or deployed? - your answer: "Partially - reviewed sometimes, not consistently"
Standard Effort: Low Target: 90 days
  • Why it ranks here: Your answer: "Partially - reviewed sometimes, not consistently"
  • What could go wrong: AI-generated code merged without the same review as human-written code is untrusted input entering your codebase unvetted - the same underlying risk as an unreviewed third-party dependency, just from a different source.
  • Attack technique: MITRE ATT&CK T1195 - Supply Chain Compromise
  • Interim step: As an interim step, require a second human reviewer specifically for any pull request that includes substantial AI-generated code, even before a formal policy distinguishes AI-assisted from human-written contributions.
  • Durable fix: Apply your existing code review and CI security-gate requirements to AI-generated output with no exception - the source of a change shouldn't determine whether it gets reviewed.
  • Suggested owner: Developers
  • Evidence it's done: Branch protection or review records covering AI-assisted changes
  • Framework references: NIST CSF 2.0: PR.PS-06 · CIS Controls v8.1: 16.1
38

Detection & Monitoring · Could you produce evidence/logs for an independent auditor showing controls operated effectively over a review period? - your answer: "Partially"
Standard Effort: Medium Target: 90 days
  • Why it ranks here: Your answer: "Partially"
  • What could go wrong: A SOC 2 Type II audit specifically tests whether controls operated effectively over a review period, not just whether they exist - without retained evidence/logs, there's nothing to actually demonstrate that.
  • Interim step: As an interim step, start retaining logs/evidence for your key controls now, even before a full audit-ready evidence program exists - gaps before today can't be recovered.
  • Durable fix: Build a systematic evidence-retention process (many GRC/compliance platforms automate this) tied to each control being tested, not manual collection at audit time.
  • Suggested owner: Compliance lead
  • Evidence it's done: Evidence repository covering the review period
  • Framework references: NIST CSF 2.0: PR.PS-04 · CIS Controls v8.1: 8.10
39

Access & Identity · How would you describe your DevSecOps practice? - your answer: "Security scanning exists but isn't enforced in the pipeline"
Standard Effort: Medium Target: 90 days
  • Why it ranks here: Your answer: "Security scanning exists but isn't enforced in the pipeline"
  • What could go wrong: Without automated security checks in the delivery pipeline, vulnerable dependencies and insecure code reach production unless someone happens to notice them in review.
  • Attack technique: MITRE ATT&CK T1195.001 - Compromise Software Dependencies and Development Tools
  • Interim step: Turn on the free dependency and code scanning your code host already offers (for example GitHub Dependabot and code scanning) and review its findings, even before making it a required gate.
  • Durable fix: Make dependency scanning and static analysis required checks in CI/CD, so builds with serious findings fail instead of shipping.
  • Suggested owner: Developers
  • Evidence it's done: Pipeline configuration showing required security checks
  • Framework references: NIST CSF 2.0: PR.PS-06 · CIS Controls v8.1: 16.1, 16.12

Combined findings - risks that compound

Combined finding - A public-facing web app that connects to a backend database, without outbound-traffic monitoring, is the setup where a SQL injection or similar attack can go unnoticed long enough to exfiltrate the database. Actions: A-exfil

  • Why this was flagged: You indicated you operate an externally-reachable customer-facing service ("Yes") connected to a backend database ("Yes"), with logging "Yes" and outbound-traffic monitoring "No".
  • Attack technique: MITRE ATT&CK T1190 - Exploit Public-Facing Application
  • What could go wrong: A public web app connected to a database is a direct target for this technique - things like SQL injection against the app itself. Centralized logging and outbound-traffic monitoring are what typically catch the follow-on data exfiltration; without them, a successful exploit can run for a long time before anyone notices.
  • Interim step: Regular vulnerability scanning helps catch some exploitable issues before they're used, but it doesn't replace monitoring for exfiltration after the fact. As an immediate step, turn on your hosting or cloud provider's built-in access/traffic logging - most include this at no extra cost, and it beats having no visibility at all.
  • How to fix it: Put a web application firewall in front of the app (most cloud providers and CDNs offer one), run an authenticated vulnerability/injection scan against it, and enable outbound-traffic alerting for unusually large data transfers - together these address the entry point, the flaw, and the exfiltration step.
  • Reference: OWASP Top 10
  • OWASP Top 10: A09:2021 - Security Logging and Monitoring Failures
Combined finding - Training is happening, but without simulated phishing tests there's no actual evidence it's working - the two are meant to reinforce each other, and skipping simulation means the training's real effectiveness is unmeasured. Actions: A-phishingSim

  • Why this was flagged: You indicated security awareness training is "Once, at onboarding" and simulated phishing tests are "No".
  • Attack technique: MITRE ATT&CK T1566 - Phishing
  • What could go wrong: Training is meant to be the human-side defense against this technique, but without testing it, its actual effectiveness is unmeasured - you know training happened, not whether it worked.
  • Interim step: Run one low-stakes test manually before investing in a platform - a single internal email from IT with a fake "reset your password" link, tracking who clicks. It's a real interim data point on whether the training is landing, at effectively no cost.
  • How to fix it: Add recurring simulated phishing tests (monthly or quarterly, many awareness-training platforms include this) and track click/report rates over time as the actual measure of whether training is working, not just completion rates.

Context notes (not scored)

No data loss prevention (DLP) product. Outbound-data monitoring is scored separately under Detect.

Compliance considerations

SOC 2 - A SOC 2 Type II audit specifically tests whether your change-management and evidence-logging controls operated effectively over the review period, not just whether they exist on paper.
Gap: Do you have documented change management controls for production systems? - answered "Informal". See A-soc2Change.
Gap: Could you produce evidence/logs for an independent auditor showing controls operated effectively over a review period? - answered "Partially". See A-soc2Evidence.

Pattern-based guidance from your own answers - not a certification audit or legal compliance determination.

Vendor-specific notes

Fortinet - Fortinet's FortiOS/FortiGate line has had multiple critical, actively-exploited authentication-bypass and RCE vulnerabilities in recent years. Regardless of current patch level: confirm firmware is on a currently-supported, patched release; avoid exposing the management interface to the internet; and enforce MFA on SSL-VPN.
Microsoft Defender for Office 365 - Check which Safe Links and Safe Attachments policies apply to which users (Microsoft's preset security policies or your own custom ones), and that every mailbox is covered - coverage depends on your plan and policy configuration.

General guidance about named products, written in advance - not a live feed and not a check of your versions. For a current check, use AI-enhanced insights below or the vendor's own advisories.

Environment snapshot (self-reported)

Organization size
11–50
Dedicated IT/security team
Our IT team takes care of both IT and cybersecurity - 3–10
Security managed by
Some services managed in-house, some outsourced
Third parties with access
6 or more
EDR / antivirus
Microsoft Defender for Endpoint
Email security gateway
Microsoft Defender for Office 365
Awareness / LMS platform
Not specified
DLP solution
No
Deployment model
Hybrid (on-prem + cloud) - Microsoft Azure
Operating systems
Windows, macOS
Network architecture
Segmented (VLANs / zones)
SD-WAN
No
External-facing devices
Yes
Firewall / VPN appliance
Fortinet FortiGate
External-facing services
Yes, DB-connected: Yes
Hosting / web stack
Microsoft Azure - IIS on Windows Server 2019
Containerization
No
Virtualization
Yes, on-prem hypervisor (e.g. VMware, Hyper-V)
Develops custom software
Yes
DevSecOps maturity
Security scanning exists but isn't enforced in the pipeline
Secrets management
Environment variables, informally managed
Limitations of this reading
  • Self-reported answers - nothing was scanned, tested or verified.
  • Framework references are SimplifiedCS's own alignment of each question to NIST CSF 2.0 and CIS Controls v8.1 - not an official crosswalk, an audit, or a compliance determination.

How scoring works · What's stored and where

AI-enhanced insights example

What the optional AI section looks like. For examples no request is made and no vulnerability source is queried, so no vulnerability items are shown.

Illustrative example - no live lookup was run. AI-generated - it can be wrong.

Sources checked

Vulnerability sources checked, per product
ProductCISA KEVNVD
Fortinet FortiGate edge device / firewall
Example report - no live lookup was run.
 Not checked (example report)Not checked (example report)
Microsoft Defender for Endpoint EDR
Example report - no live lookup was run.
 Not checked (example report)Not checked (example report)

Patterns across your answers

Free personal AI tools are in use with no usage policy, while client software is developed in-house
Staff pasting client code or data into unmanaged AI tools is a realistic leak path for a consultancy, and nothing in these answers limits it. It sits alongside - not inside - the scored AI governance gap, because it's the combination with client work that raises the stakes.
Based on: "Which of the following describes how AI is used in your environment?"; "Is the organization's use of AI tools tracked and governed?"; "Does your organization develop or maintain custom software/applications?"

Summary

In this example, day-to-day protections such as endpoint coverage, logging and isolated backups are in place. The gaps that matter most are MFA covering admin accounts only in a hybrid environment, and incident and continuity planning that hasn't been tested.

  • This is an illustration of the AI-insights format using fictional answers. No vulnerability sources were queried for it.