The enterprise security checklist for 2026

Practical security for a growing or larger organisation with a dedicated IT or security function. Work through it as a program: identity and access first, then the controls and governance that keep holding as you scale.

updated
September 2026
mapped to
NIST CSF, ISO 27001, CIS Controls

In short. An enterprise security checklist is a prioritised program of controls for an organisation of roughly 100+ people with a dedicated security function. Each item below is tagged Required, Recommended, or Optional, and follows the NIST Cybersecurity Framework, ISO/IEC 27001, and CIS Controls (IG2 / IG3).

01

Identity and access at scale

At 100+ people, access is your biggest attack surface. Automate it, or it drifts.

Required
Put every app behind single sign-on with strong MFA

Consolidate logins into an identity provider and enforce phishing-resistant MFA (hardware keys or passkeys) for admins and anyone touching sensitive systems. Retire standalone passwords wherever you can.

Required
Enforce least privilege with role-based access, reviewed regularly

Grant access by role, not by person, and run access reviews on a schedule. Most breaches escalate through over-privileged accounts nobody revisited.

Required
Automate joiner, mover, and leaver so access follows the person

Wire onboarding and offboarding to your HR system so access is granted and revoked automatically. Manual offboarding at scale always leaves dormant accounts behind.

Vault privileged access and rotate secrets

Put admin credentials and service-account secrets in a privileged-access or secrets manager, rotate them, and log their use. Standing admin rights are the prize attackers work toward.

02

Endpoints and the device fleet

Required
Enrol every device in management, with encryption and patch compliance enforced

Use an endpoint-management tool to require disk encryption, current patches, and a screen lock on every laptop and phone, and block devices that fall out of compliance.

Required
Run EDR on every endpoint and route its alerts somewhere staffed

Endpoint detection and response catches what antivirus misses, but only if someone acts on the alerts. Feed them into your monitoring, not a dashboard nobody watches.

Gate access on device posture

Let only managed, healthy devices reach sensitive apps. A valid password from an unmanaged laptop should not be enough. Conditional access ties the two together.

03

Data governance

Required
Classify your sensitive data and know where it lives

You cannot protect or prove compliance on data you have not mapped. Classify what is sensitive (customer, financial, regulated) and track where it is stored and who can reach it.

Required
Encrypt data at rest and in transit, and manage your keys

Encrypt everywhere by default and control the keys. Review who can decrypt as carefully as who can access.

Add data-loss prevention on the paths data actually leaves by

Put DLP on email, file sharing, and endpoints to catch sensitive data heading out, and tune it so it helps rather than nags.

Run access reviews and enforce retention

Periodically re-certify who has access to what, and delete data you no longer need. Less retained data is less to lose.

04

Network and cloud

Required
Harden your cloud configuration and watch it continuously

Use posture tools (CSPM or your provider’s own) to catch public buckets, open security groups, and risky IAM. Misconfiguration, not exotic exploits, is how most cloud data leaks.

Required
Segment your network and move toward zero trust

Stop treating the internal network as safe. Segment it, authenticate every request, and give apps and services the least access they need.

Control egress and secure remote access

Restrict outbound traffic to what is needed, and replace flat VPN access with identity-aware, least-privilege remote access.

05

Detection and response

Required
Centralise logs and alert on what matters

Send identity, endpoint, cloud, and application logs to one place (a SIEM or equivalent) and build alerts for the events that signal an attack, not just noise.

Required
Make sure someone is watching, around the clock

Detection only works if a human or service responds. Staff it in-house or with an MDR or SOC partner, with clear escalation.

Required
Have an incident response plan and rehearse it

Write the runbook (roles, containment, comms, legal, regulators) and run a tabletop at least once a year. The first time you use it should not be during a real breach.

06

Application and product security

Required
Build security into the SDLC with automated checks in CI

Add SAST, dependency scanning, and secrets scanning to your pipelines so issues are caught before release, and make fixing them part of the definition of done.

Required
Penetration test regularly, and test what you ship between releases

Test your applications, network, and cloud at least annually and after major changes, and continuously for your highest-risk surfaces. A scan finds the known; a pentest finds the exploitable.

Run a vulnerability disclosure or bug bounty program

Give outside researchers a sanctioned way to report what they find, with someone inside to triage and drive fixes.

07

AI governance

AI is now part of your attack surface and your compliance story. Govern it deliberately.

Required
Inventory where AI is used, and set an acceptable-use policy

Know which AI tools, assistants, and features are in use across the company, and set a clear policy on what data may never go into a public one. Shadow AI is now a leading path for data to leave.

Required
Control what data reaches AI providers, and confirm they do not train on it

Before customer or regulated data flows into an AI feature or vendor, confirm in writing it is not used for training, and apply the same access controls you would to any other data path.

Test the AI in your own product like any other attack surface

If you ship AI features, test them for prompt injection, data leakage, and tool abuse, and keep a human in the loop for consequential agent actions. Our AI application security checklist covers this in depth.

08

Governance, risk, and compliance

Required
Name an accountable security owner and keep a risk register

Someone (a CISO, vCISO, or security lead) must own the program, maintain a risk register, and report to leadership. Security without an owner drifts.

Required
Run a real security-awareness program, including phishing simulations

Train everyone, simulate phishing, and measure it. People are targeted first at every size, and at 100+ the odds someone clicks go up.

Pursue SOC 2 or ISO 27001, and align to a framework

Align your controls to NIST CSF or the CIS Controls and pursue the certification your customers ask for. It structures the work and becomes sales evidence.

Plan for continuity and disaster recovery, and test restores

Know your recovery objectives, keep tested and offline-capable backups, and rehearse recovering critical systems. Ransomware resilience is a business-continuity problem.

Frequently asked questions

What is an enterprise security checklist?

A prioritised set of the security controls a growing or larger organisation (roughly 100+ people, with a dedicated IT or security function) should have in place: identity and access, endpoints, data governance, network and cloud, detection and response, application security, AI governance, and the security program that runs them.

What security controls does a company with 100+ employees need?

Single sign-on with strong MFA, role-based least-privilege access with regular reviews, managed and encrypted endpoints with EDR, centralised logging with someone watching, a secure SDLC with regular penetration testing, third-party and AI governance, and a named owner running the program against a framework like NIST CSF or ISO 27001.

How often should a company do a penetration test?

At least once a year and after any major change, with continuous or more frequent testing for your highest-risk, internet-facing, and customer-data systems. Many customers and auditors now expect at least annual testing as evidence.

What is the difference between vulnerability scanning and penetration testing?

A vulnerability scan is automated and tells you what is known to be broken. A penetration test is human-led and tells you what is actually exploitable, including business logic, chained attacks, and access paths a scanner cannot reason about.

Which security framework should a growing company align to?

NIST CSF or the CIS Controls give you a practical baseline, and SOC 2 or ISO 27001 give you the certification customers ask for. Pick the one your buyers and regulators expect, and align your controls and risk register to it.

Where SecureLayer7 fits

Most of this is your team’s work. Where an outside offensive perspective earns its keep is proving what an attacker could actually reach, on a cadence your auditors and board can see.

Pentest on a cadence, not once a year

CREST-accredited and CERT-In empanelled testers cover your applications, network, and cloud on the schedule your risk demands, and hand your teams findings they can fix, with a re-test to confirm.

Continuous coverage between engagements

BugDazz keeps testing your external attack surface as you ship, so new exposure surfaces as a finding rather than an incident, between scheduled pentests.

Reports your auditors and board accept

Every engagement produces evidence your SOC 2 or ISO 27001 auditors and your board take seriously, mapped to the risks on your register.

Sources

Prove the controls hold

See what an attacker could actually reach across your stack.

We scope penetration testing and red teaming across your applications, network, and cloud, on the cadence your risk and your auditors require, and hand your teams findings they can fix.