An enterprise security programme is not a stack of tools and it is not a certification. It is a set of decisions about what you are protecting, who is accountable for each part, what you will do when something fails, and how you will prove all three. Organisations that have one can answer those questions in a meeting without preparation. Organisations that do not have one can pass an audit and still be unable to describe how an attacker would get from a phishing email to their finance system.
This guide is about building the programme rather than buying it. It starts from the position most mid-market organisations are actually in - no complete asset inventory, no single owner, a flat budget and several regulations arriving at once - and works outward: governance, risk register, inventory, identity, endpoints, vulnerability management, detection, recovery, third parties, the regulatory map, evidence, budget, people, a twelve-month sequence and the metrics that make a board conversation possible.
Two framing choices. First, it is written for organisations with between roughly fifty and two thousand staff, where the security function is a handful of people rather than a department. Second, it assumes you will be judged on outcomes you can show - an inventory that is current, a restore that was tested, an incident that was contained in hours rather than weeks - not on the number of controls you can name.
Remote Monitoring Offers
Choose Sphnix first, then compare mSpy and Eyezy.
What a security programme is, and what it is not
A programme is a repeatable loop: something identifies what you own, something decides how much each thing matters, something applies a control, something detects when the control fails, something responds, and something records what happened so the next iteration is better informed. Every element has an owner and a cadence. That is the whole structure, and it is the same structure whether you map it to NIST, ISO or a regulator's questionnaire.
What a programme is not: a product list, a certification badge, a policy library nobody has read, or a maturity score produced by a vendor that sells the next tier. Those things can be outputs of a programme. On their own they produce the familiar failure mode - an organisation with ISO 27001 on the wall, an EDR console with no one watching it, and a backup system whose restore has never been attempted.
The distinction has a practical test. Ask three questions: which systems would stop the business if they were unavailable for a week, who decided that, and when was it last checked? If the answers come from memory, there is activity but no programme. If they come from a document with a date and a name, there is a programme - possibly an immature one, which is a solvable problem.
The starting position nobody admits to
Almost no organisation starts with a clean inventory and a budget. The realistic starting position is: a spreadsheet of servers that is eighteen months old, cloud accounts created by individual teams, a SaaS estate discovered mostly through the finance system's vendor payments, an identity provider that half the company uses, one person who is nominally responsible for security alongside two other jobs, and a regulator's letter asking for evidence of measures that were never documented.
The correct response is not to spend six months producing a perfect baseline. It is to establish a smallest-viable loop and iterate. Concretely: pick the identity provider as the spine, export the user list, reconcile it against HR within a fortnight, discover the cloud accounts through billing rather than through interviews, and write down what you found with the date and the method. A rough inventory in two weeks beats an accurate one in two quarters, because the point of the first iteration is to find the things that are on fire.
Two rules keep the iteration honest. Write down what you did not cover, explicitly, so that the gap is a managed decision rather than an omission. And date every artefact, because an undated document cannot be used as evidence of anything - not to a board, not to an auditor, not to a regulator.
Governance: the four decisions that need a name on them
Governance is the part of the programme that most organisations treat as paperwork, and it is the part that determines whether anything else happens. Four decisions need an accountable individual, documented authority and a review cadence.
Risk acceptance. Someone must be able to say "we know this exposure exists and we accept it, with these compensating controls, until this date". That authority has to sit with an executive who can be asked about it, not with the security team, because the security team cannot accept business risk on the business's behalf. Without this, every unmitigated finding becomes an argument, and the security function spends its credibility on decisions it was never empowered to make.
Funding and priority. A named budget holder decides what the programme gets, and the trade-off is recorded. "We did not fund endpoint detection because we chose to fund the ERP migration" is a legitimate decision when it is written down and revisited. The same absence of funding is negligence when nobody can say who decided it.
Incident authority. During an incident, someone has to be able to authorise taking a system offline, notify a regulator, engage outside counsel and inform customers, without a committee meeting. Decide who that is, decide the deputy, and write the thresholds that trigger escalation. Two hours of ambiguity at the start of an incident costs more than most controls the programme will buy all year.
Exception handling. A time-boxed exception process with an owner, a compensating control and an expiry date is the difference between a policy that reflects reality and one that is quietly ignored. Every exception should be visible on the same register as the risks it creates.
The governance minimum, if you are starting today
- A one-page security charter naming the accountable executive, the programme owner and the escalation path.
- A risk register with owners, not just entries - twenty risks with names beat two hundred without.
- An incident authority matrix with money thresholds and notification triggers.
- A quarterly review that produces decisions, minuted, rather than a status update.
- A single evidence folder with a naming convention and a date on every file.
The regulatory backdrop has made this less optional than it used to be. NIS2 makes management-body members personally accountable for approving and overseeing risk-management measures and requires them to undergo training; DORA puts the management body formally in charge of ICT risk. A governance structure that exists only on paper is now an exposure in its own right, and the first question in an examination is usually who decided.
Risk: a register that survives contact with the board
Most risk registers fail for the same reason: they are written for the security team rather than for the people who allocate money. A register that a board can act on has four properties.
It is expressed in business terms. "Unpatched internet-facing VPN with a known exploited vulnerability" is a technical finding; "remote access to the finance system can be compromised by an attacker using a publicly known exploit, with an estimated four-day outage and a regulatory notification" is a decision. Both belong in the register, but the second is the sentence that gets funded.
It is scored consistently and simply. Likelihood and impact, each on a defined scale with anchors - what "likely" means in incidents per year, what "major" means in currency or customers affected - beats a five-by-five grid with no definitions. Consistency matters more than sophistication, because the register's job is to compare one risk against another.
It has an owner who is not the security team. The owner of "customer data exposed through a misconfigured storage bucket" is the person who runs the team that creates buckets, because they can change the outcome. A register where every risk is owned by the CISO is a register of things nobody else has agreed to.
It changes. A quarterly review that adds what happened, retires what was fixed and re-scores what moved is the minimum. Stale registers are worse than none, because they create the appearance of management while documenting that nobody looked.
Inventory: the asset list is the programme
Every control in the programme is applied to something, and you cannot protect what you have not listed. That is why the inventory is not an administrative chore - it is the substrate. An organisation that knows its estate can route a vulnerability to an owner in minutes; one that does not will spend a week asking who owns a hostname while the exploit is public.
Four inventories, reconciled against each other, do most of the work. The identity inventory is the authoritative list of accounts, taken from the identity provider and reconciled to HR; it is the spine because almost every compromise becomes an authenticated session eventually. The device inventory comes from the endpoint management agent, not from a spreadsheet, and should be reconciled against the DHCP or network logs so that unmanaged devices appear as gaps. The application and data inventory is the hardest and the most valuable: which business processes depend on which systems, and which systems hold regulated data. The cloud and SaaS inventory comes from billing and from cloud-native tooling, because shadow IT is discovered through invoices long before it is discovered through interviews.
Two mechanics make the inventory usable. First, attach an owner to every entry - a team and a named person - because an unowned asset cannot be patched, decommissioned or accepted. Second, record the data classification alongside it, in a small number of categories, and keep the classification decision with the business owner rather than with security. A four-level scheme that people actually apply beats a twelve-level taxonomy that nobody does.
The test of an inventory is not completeness on paper. It is time-to-owner: pick a random hostname from your external attack surface and time how long it takes to reach a person who can act on it. If the answer is more than a working day, the inventory is a document rather than a control.
Identity and access as the first technical control
If you can only fund one technical control this year, fund identity. The reason is structural: nearly every intrusion path ends in a valid credential or a valid session, so the controls around authentication and authorisation sit in front of the majority of the attack surface at once. It is also the control with the clearest evidence trail, which matters when a regulator asks what you did.
The sequence that produces the most risk reduction per unit of effort: single sign-on for every application that supports it, so that the identity provider becomes both the choke point and the log source; phishing-resistant authentication for administrators and for anyone who can approve payments or move data, meaning passkeys or hardware keys rather than push notifications; conditional access that treats location, device compliance and session risk as inputs rather than trusting a successful login forever; and privileged access management that removes standing administrator rights in favour of just-in-time elevation with an approval and an audit record.
Then the unglamorous half: joiners, movers and leavers driven from the HR system rather than from tickets, with a reconciliation each month that lists accounts with no matching employee, service accounts with interactive login enabled, and dormant accounts that have not authenticated in ninety days. In most organisations the first reconciliation finds more genuine risk than the first penetration test does, because the accumulation of legitimate-but-stale access is where insider and attacker both operate.
Multi-factor authentication deserves a specific warning. Push-based approval is phishable and fatigable, and the number of incidents that begin with someone approving a prompt they did not initiate is not small. Number matching helps, but the durable answer is a credential that cannot be relayed - a passkey or a security key - for the accounts that matter most, with authenticator apps for the rest and SMS as a legacy exception you are actively retiring.
Endpoint, patching and the exploit window
The exploit window - the time between a vulnerability becoming publicly known and being used against you - has compressed to days for the vulnerabilities that matter, and to hours for the small set that attackers weaponise immediately. Patching is therefore a scheduling problem with a service-level commitment, not a project.
A workable policy has three tiers and a documented exception path. Internet-facing systems with a known exploited vulnerability: remediate within 72 hours, or remove from the internet, or compensate with a control you can name. Internet-facing systems with critical severity but no known exploitation: within 14 days. Everything else: a monthly cycle, with the caveat that "everything else" includes the identity provider's agents and the backup infrastructure, which are the two things attackers target precisely because organisations forget them.
The prioritisation input matters as much as the timetable. CVSS alone produces a queue dominated by theoretical issues; the CISA Known Exploited Vulnerabilities catalogue, vendor advisories on actively exploited flaws, and your own exposure data - is this service reachable, does it need credentials, does it hold regulated data - produce a queue that reflects reality. The combination is the practical answer: exploited first, then exposed, then severe.
Endpoint control has converged on a similar shape. Endpoint detection and response on every device that can reach corporate data, including the laptops of contractors and the servers, with alerts routed to a person or a service that will act on them at three in the morning. Application allow-listing where the operational cost is tolerable - call centres, engineering workstations, anything that runs one job. Disk encryption with keys escrowed, because a stolen laptop is a breach notification question rather than an inconvenience. And a documented build standard, so that a new machine is compliant by default rather than by inspection.
Vulnerability management that is not a scan report
A scanner produces findings; a vulnerability management process produces remediation with dates. The difference is entirely in the workflow around the tool: who receives the finding, how it is triaged against exposure and business context, who commits to a date, and how closure is verified.
The operational details that decide whether it works: deduplicate by asset and vulnerability so that a hundred findings on one host become one ticket; assign tickets to the team that owns the asset rather than to a central queue; require a fix or a documented acceptance, never "risk accepted" as a free-text field; verify closure by rescanning, not by trusting a change ticket; and report the two numbers that matter to management - the ageing of open critical and high findings, and the proportion of findings past their remediation date.
Two additions raise the value substantially. Authenticated scanning and cloud-native posture assessment catch the misconfigurations that scanners miss and that attackers use more often than they use memory corruption. And an external attack-surface review, run quarterly from outside the perimeter, finds the forgotten hostname, the staging environment with a default page, the marketing microsite on a third-party platform, and the development API that never had authentication - the things your internal scanner was never pointed at.
Detection and response: coverage over tooling
Detection is where programmes most often buy capability without building it. A SIEM that ingests everything and alerts on nothing useful is a licence, not a control. The question to answer first is what you would need to see to catch the five or six attack paths that would actually hurt you, and then whether you can see it.
That is the useful application of MITRE ATT&CK: not as a compliance checklist to colour in, but as a vocabulary for asking "would we detect credential dumping on a server", "would we notice a new OAuth application granted mail access", "would we see a backup catalogue being deleted". Pick the techniques that correspond to your real risks, write a detection for each, and record which ones you cannot yet detect so that the gap is a decision rather than a surprise.
Response is a separate capability with its own artefacts: a plan with roles, an escalation matrix with names and numbers, a communications template, a forensic evidence procedure that preserves logs before they rotate, and a tabletop exercise at least twice a year. The exercise is the cheapest control in the programme and the one that most reliably exposes the things that will go wrong - the person who cannot be reached, the backup that needs a password nobody has, the legal question nobody thought to ask, the supplier who cannot be contacted at the weekend.
Keep the plan short enough to use. A forty-page document is read by nobody during an incident; a four-page decision tree with an appendix of contacts is read by everybody. And record the dates of exercises and the actions that came out of them, because that record is what turns "we have a plan" into evidence that the plan has been tested.
Backups and recovery: the control that ends ransomware
Most ransomware incidents are not encryption events; they are recovery failures. The organisations that come back in days rather than months had backups that were immutable, tested and documented. The ones that paid, or waited weeks, discovered during the incident that the backup catalogue had been deleted, that the retention was 30 days and the encryption happened 45 days before detection, or that nobody had ever restored more than a single file.
The design rule is 3-2-1-1-0: three copies of the data, on two different media, one offsite, one offline or immutable, and zero errors on restore testing. The last two digits are the ones organisations skip. Offline or immutable is what defeats an attacker with domain administrator rights, because deletion of an immutable copy requires waiting out the retention period rather than issuing a command. Zero errors on restore means a scheduled test that restores real systems, with a measured time to restore and a record of who ran it.
Three details turn backup into resilience. Keep the backup infrastructure out of the domain it protects, with separate credentials and separate administrator accounts, so that a compromised identity cannot reach both. Protect the backup catalogue as carefully as the data, because catalogue destruction is a common pre-encryption step. And decide the recovery time and recovery point you actually need per business process, in writing, with the business owner: a 24-hour target for the finance system and a four-hour target for the customer portal imply different architectures and different costs, and choosing them under pressure is choosing them badly.
Third parties: the register, the exit plan and the contracts
The supply chain is now the most common route into a mid-market organisation, because attackers prefer the supplier whose credentials reach many customers over the customer who has a firewall. The programme's response has three parts: know who the suppliers are, know what access they have, and know what you would do if one of them disappeared tomorrow.
The register should be boring and complete: supplier name, service, data categories, whether access is to systems or only to data, contract end date, security attestation (a current SOC 2 Type II or ISO 27001 certificate, read for scope rather than for the logo), the named internal owner, and the criticality tier. The tiers decide the depth of due diligence: a tier-one supplier that processes customer data or has production access gets a questionnaire, a review of its attestation and a contractual security schedule; a tier-three supplier that ships stationery gets a payment check.
Two obligations have made this less discretionary. Under DORA, financial entities must maintain a register of information on ICT third-party arrangements and document exit strategies for critical ones. Under NIS2, essential and important entities are responsible for the security of their supply chain, which in practice means evidence that suppliers were assessed and that contractual security requirements exist. Even outside those regimes, the practical argument is the same: the conversation you want with a breached supplier is one where you know exactly what they held.
Contracts carry the controls that procurement does not. Security requirements with a defined standard, a notification obligation with a stated timeframe - shorter than the regulatory clock, so that you can meet your own - a right to audit or to receive audit reports, data-return and deletion obligations at termination, sub-processor disclosure, and breach cost allocation. Review them when the regulator changes, not only at renewal.
The regulatory map: NIS2, DORA, GDPR, CRA, SEC
Most mid-market organisations are now inside at least two regimes and often four, and the instinct to treat each as a separate project is what makes compliance expensive. The regimes differ in scope and in deadline; they converge on the same underlying measures, which is why a single programme with a mapped evidence set satisfies all of them.
NIS2 (Directive (EU) 2022/2555) applies to essential and important entities across a wider set of sectors than its predecessor, and it changes three things materially. Article 21 requires risk-management measures covering a defined list including incident handling, business continuity, supply-chain security, vulnerability handling, cryptography and access control. Article 20 puts the management body formally in charge, with personal accountability and a training obligation. Article 23 sets the reporting clock: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month. That 24-hour clock is the one that changes behaviour, because it starts before you know the scope.
DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025 to financial entities and to their ICT providers by contract. Its distinctive demands are the ICT risk-management framework with management-body accountability, the register of information on third-party arrangements, exit strategies for critical providers, incident classification and reporting, and resilience testing including threat-led penetration testing for the most significant entities.
GDPR overlaps on outcomes: Article 32 requires appropriate technical and organisational measures, and Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal-data breach, with Article 34 requiring communication to individuals where the risk is high. The clock is the same shape as NIS2's and the evidence is the same evidence.
The Cyber Resilience Act (Regulation (EU) 2024/2847) shifts the frame from operator to product: it entered into force in December 2024, its vulnerability and incident reporting obligations apply from 11 September 2026, and full application follows from 11 December 2027. If you place products with digital elements on the EU market - including firmware and software embedded in hardware - the obligations run to secure-by-default design, vulnerability handling, coordinated disclosure and support periods, and they apply to the manufacturer rather than to the customer.
SEC disclosure rules matter for US-listed organisations: a material cybersecurity incident must be described in Item 1.05 of Form 8-K within four business days of the materiality determination, which means the materiality decision itself needs a documented process rather than an argument held during the incident.
The efficient response is a control matrix with one row per measure and one column per regime, showing which evidence satisfies which obligation. Most rows are shared. The genuinely regime-specific work is small: the 24-hour NIS2 warning, the DORA register and exit plans, the CRA product lifecycle, the 8-K materiality process.
Evidence: one artefact, many regimes
Compliance fails on evidence far more often than on controls. An organisation that patches well but cannot show a dated record of the decision, the ticket and the verification will be treated as though it did not patch at all. The fix is a small discipline applied consistently: every control produces an artefact, every artefact is dated, and every artefact lives in one place with a naming convention.
What auditors and regulators actually accept is narrower than people expect, and it is worth knowing the shape. A policy that is signed and versioned. A register that is dated and current. A ticket trail showing the finding, the owner, the fix and the verification. A restore test with a date, a duration and a result. An exercise with participants and actions. A supplier assessment with an attestation on file. A training record with names and completion dates. None of these require expensive tooling; all of them require someone to have decided that producing them is part of the job.
Two practical habits. Build the evidence pack as you go, not in the fortnight before an audit, because reconstructed evidence is obvious and worthless. And keep the artefacts out of the systems they describe - an incident report stored only on the file server that the incident took offline is a lesson in why the evidence folder needs its own access path.
Budget: allocation logic when the number is flat
Most security budgets are decided by precedent: last year's number, plus or minus a percentage. The useful contribution is not a benchmark from a survey but an allocation logic that can be defended line by line and adjusted when the total changes.
A shape that works for mid-market organisations, expressed as shares rather than absolute figures: roughly a quarter to identity, endpoint and platform controls, because that is where the majority of risk reduction sits; a quarter to detection and response, including whatever is outsourced; ten to fifteen per cent to resilience - backup, immutability, restore testing, business continuity; a quarter to people and specialist services; and five to ten per cent to assurance - penetration testing, red team exercises, audits, tabletop facilitation. The remaining margin covers licences, training and the unglamorous renewal creep that consumes budgets quietly.
Three rules make the allocation survive scrutiny. Fund the boring things first - backups, identity, patching - because they are the controls that determine whether an incident is a bad week or a lost quarter. Treat tool consolidation as a budget line, because the average mid-market estate carries overlapping products that each solved a problem once and now consume both licence and attention. And reserve a contingency, because the year will contain at least one event - an acquired company, a regulator's questionnaire, a critical vulnerability in something you cannot patch - that was not in the plan.
The board conversation is easier when the ask is tied to a decision rather than to fear. "We are asking for X to move MFA to phishing-resistant factors for 40 privileged accounts and to test restores quarterly" is fundable. "We need more security budget" is not, and it teaches the board that the request is unfalsifiable.
People: the first three hires and the MSSP decision
With a small team, the shape of the roles matters more than the headcount. The first three hires in most mid-market programmes are a hands-on security engineer who can configure identity, endpoint and cloud controls; a detection and response person who can write detections and run an incident; and someone who owns governance, risk and evidence - a role that is often filled part-time by an experienced contractor at the start.
What does not work is a team of one generalist with a ticket queue and no authority, or a team that is entirely advisory and cannot change a configuration. The programme needs at least one person who can implement, because recommendations without implementation capacity become a document that lists everything the organisation has not done.
The managed service decision should follow the coverage question rather than the cost question. If you cannot staff 24x7 detection, an MSSP that provides monitoring with a defined escalation path into your team is usually better value than a tool nobody watches overnight. The criteria that decide the outcome: what exactly is monitored and at what depth, what the escalation and response commitments are in writing, whether the service can act or only alert, how the handover works during an incident, and what happens to the telemetry when the contract ends. Ask for a sample incident timeline from a real customer, not a reference logo.
Awareness training is part of the people budget and is usually done badly. Annual slide decks change little; short, frequent, role-specific exercises change more - a phishing simulation with a debrief rather than a league table, a finance-specific payment-fraud drill, a developer session on secrets in repositories. Measure behaviour, not completion: the number of reported suspicious emails is a better indicator than the percentage who finished a module.
Year one: a 12-month sequence that fits in a real calendar
Programmes fail when the plan is a list of everything rather than a sequence of things that fit. The sequence below assumes one to three people, a flat budget and a genuine backlog; it is ordered so that each quarter produces something an executive can see and an auditor can file.
Quarter one: see the estate and stop the obvious. Reconcile identity against HR. Turn on single sign-on for the applications that support it. Enforce phishing-resistant authentication for administrators. Export the cloud and SaaS inventory from billing. Fix the handful of findings that are internet-facing and exploited. Write the charter, name the owners, and start the risk register with twenty entries. Deliverable: an inventory with owners and a first risk register.
Quarter two: make recovery credible. Implement 3-2-1-1-0 with immutable copies and separate credentials. Run the first real restore test of a business-critical system and record the time. Set the patching tiers and the exception process, and start reporting compliance against them. Complete the first tabletop exercise. Deliverable: a restore test record and a patching SLA with real numbers.
Quarter three: see the attack. Deploy or tune detection against the six attack paths in the risk register, using ATT&CK as the vocabulary. Enable centralised logging with retention that matches your regulatory exposure. Run an external attack-surface review and remediate the forgotten assets it finds. Start the supplier register, tier it, and assess the tier-one suppliers. Deliverable: detection coverage mapped to risks, with the gaps written down.
Quarter four: prove it and plan the next year. Commission an independent penetration test scoped to the risks rather than to the compliance checklist. Run the second tabletop with the executive team. Complete the evidence pack and map it across the regimes that apply. Present the board metrics with a decision attached to each gap. Deliverable: an evidence pack, a tested plan, and a budget request tied to decisions.
What this sequence deliberately does not do: it does not start with a policy rewrite, a certification project or a tool procurement. Those can follow once the loop exists. Organisations that begin with the certificate tend to end with a certificate; organisations that begin with the inventory and the restore test tend to end with both a programme and, later, a certificate that means something.
Metrics a board can act on
A board does not need a dashboard of two hundred indicators. It needs a small number of measures, each with a trend, a target and a named owner, and each connected to a decision. Ten measures are enough for a mid-market programme.
Inventory coverage and time-to-owner: the proportion of known assets with an owner, and the median hours to reach the person who can act on a given asset. The second number is the one that predicts incident performance.
Authentication strength: the share of privileged accounts using phishing-resistant factors, and the share of all users on any second factor. Two numbers, both moving in one direction.
Patch compliance: the proportion of critical and known-exploited findings remediated inside the SLA, plus the count past due. Report both, because a high compliance rate with a large overdue tail is a different story from a moderate rate with none.
Recovery evidence: the date of the last successful restore test, the measured restore time for the top three business processes, and whether it met the target. A date is more persuasive than a percentage.
Detection coverage: the number of the top attack paths with a tested detection, out of the total identified. The gap list is the roadmap.
Incident performance: time to detect and time to contain, median and worst case, from real events and exercises rather than from aspirations.
Supplier assurance: the proportion of tier-one suppliers assessed in the last twelve months, and the number with a current attestation on file.
Exceptions and accepted risks: the count of open exceptions with their expiry dates, and the count that have expired without a decision. That second number is the most honest indicator of whether governance is real.
Present them as a one-page trend with three colours and a sentence of commentary each. The commentary is where the programme's judgement shows: what moved, why, and what decision is being requested.
Conclusion: build the loop, then make it faster
The difference between an organisation that survives a serious incident and one that does not is rarely the sophistication of its tools. It is whether the basics were owned: an inventory with names against it, identity that cannot be phished, endpoints that update, a backup that restores, a plan that was tested, suppliers that were assessed, and evidence that was produced as a by-product of doing the work rather than reconstructed afterwards.
That is achievable with a small team and a flat budget, in a year, if the work is sequenced and each quarter produces something visible. The regulatory deadlines - 24 hours to warn under NIS2, 72 hours to notify under GDPR, four business days for an 8-K, the CRA's reporting clock from September 2026 - are not a separate programme. They are the same programme, seen from the outside, with a stopwatch attached.
Where this connects to the rest of our work: the technical depth on identity and endpoint controls is in our zero trust overview and the enterprise VPN and network access guide; the incident side is in the incident response plan guide; the account-level controls that individuals own are in the social media security guide; and background and insider controls are in the pre-employment screening guide. The Italian version of this guide is at programma di sicurezza aziendale.
Where to start this week
If you need the programme assessed rather than described, tell us the size of the estate and the deadline you are working to and we will say what we would look at first. Organisations that want the technical baseline built - external attack surface, identity configuration, detection coverage, restore testing - can start from our security hardening engagement, scoped to systems you own or are authorised to test.
Sphnix Monitoring Dashboard
Track messages, location, social media and activity signals with an authorized monitoring dashboard.
Try Sphnix Now →Related Sphnix Features:
Need Professional Help?
Hire verified ethical hackers for authorized recovery, security testing and incident support.
Hire a Hacker →Professional Services
Explore cybersecurity services for audits, recovery, forensics and defensive hardening.
View Services →Questions? Our experts are ready to help.
Contact Us for Free Consultation →Frequently Asked Questions
A repeatable loop rather than a product list: something that identifies what the organisation owns, something that decides how much each thing matters, controls applied to those things, detection when a control fails, response when detection fires, and a record of what happened so the next iteration is informed. Every element has a named owner and a cadence. NIST CSF 2.0 and ISO 27001:2022 describe the same loop in different vocabulary; the programme is the operating version of it.
Establish a smallest-viable loop in weeks rather than quarters. Use the identity provider as the spine and reconcile the account list against HR; discover cloud and SaaS estates through billing rather than interviews; fix the internet-facing issues that are already being exploited; and write down what you did not cover, with dates. A rough inventory with owners in two weeks finds more real risk than an accurate baseline in two quarters.
Identity, then recovery. Nearly every intrusion path ends in a valid credential or session, so single sign-on plus phishing-resistant factors for privileged accounts reduces the most risk per unit of effort. Backups come second because most ransomware incidents are recovery failures, and an untested backup is a hypothesis. Detection, testing and certification projects follow once those two are real.
Under Article 23 of Directive (EU) 2022/2555 an affected entity must send an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. The 24-hour clock is the one that changes operating behaviour, because it starts before the scope is fully known - which is why the incident plan needs a pre-agreed notification template and a named decision-maker.
NIS2 is a directive applying to essential and important entities across many sectors, transposed into national law, and organised around risk-management measures with management-body accountability. DORA is a regulation that applies directly to financial entities and their ICT providers, and adds specific artefacts: an ICT risk-management framework, a register of information on third-party arrangements, exit strategies for critical providers, incident classification and reporting, and resilience testing including threat-led penetration testing for the most significant entities. Many financial entities are caught by both, and the evidence overlaps heavily.
For a mid-market organisation, three roles cover the core: a hands-on engineer who can configure identity, endpoint and cloud controls; a detection and response person who writes detections and runs incidents; and someone who owns governance, risk and evidence, often part-time or contracted at the start. The critical constraint is implementation capacity - a team that can only advise will produce documents listing everything the organisation has not done.
Decide on coverage, not on price. If you cannot staff 24x7 detection with a defined escalation path, an MSSP that monitors at a known depth and can hand over cleanly during an incident is usually better value than a tool nobody watches overnight. Ask what is monitored, what the response commitments are in writing, whether the service can act or only alert, and what happens to your telemetry when the contract ends.
A small set, each with a trend, a target and an owner: inventory coverage and median time-to-owner; the share of privileged accounts on phishing-resistant factors; patch SLA compliance plus the overdue count; the date and result of the last restore test; detection coverage against the top attack paths; median and worst-case time to detect and contain; tier-one supplier assessments completed; and open or expired exceptions. One page, three colours, a sentence of commentary per line, and a decision attached to each gap.
