The Enterprise Security Handbook

01Why this handbook

For most organisations, security was something IT bought. A firewall at the edge, antivirus on the endpoints, a compliance exercise and an annual audit to close it. It sat on the budget as a cost centre, and success meant that nothing happened.

That model has not survived the way organisations now work. Applications run across data centres, clouds and software services. Users sign in from anywhere. Regulators ask for evidence rather than intent, and customers ask the same questions before they sign. Security is now judged on whether the business can keep operating, and whether it can show how.

Along the way, most enterprises have been offered a trade. Move the estate to a large provider and its security tooling comes with it, fast and well built, along with its control plane, its logs and often its keys. Keep everything in-house and you keep control, but you build and run every control yourself. Speed or control. Pick one.

This handbook does not accept that trade. It is a working reference for the people who have to make security real: what you are defending against, how to organise the controls, how to run operations and recovery, how compliance fits, and who is responsible for what.

02The pressures you are defending against

Threats change names every year. The patterns underneath them are steadier, and four of them account for most of the damage an enterprise will face.

First, most of these begin with something the organisation controls: who holds which access, and how services are configured. Prevention is largely a matter of discipline rather than exotic tooling.

Second, attackers increasingly go after recovery itself. Ransomware that finds and encrypts the backups turns an incident into a crisis, which is why recovery sits in this handbook alongside prevention rather than in a separate continuity plan.

Compliance failure belongs on the list as well. The cost is rarely the penalty alone. It is the disruption of remediating under scrutiny, and the questions customers ask afterwards.

03Resilience is the goal

No organisation prevents every incident. The ones that come through well assumed an incident would happen and built for it: protect what they can, detect what gets through, and recover quickly when it matters.

Assume something gets through. Build for how fast you know, and how fast you recover.

In practice, that thesis becomes a cycle of five stages. Each needs an owner, and each should produce something you can show.

1. Protect — identity, access, hardening, segmentation and encryption for users, applications and infrastructure. Evidence: the policies in force and where they apply.
2. Detect — telemetry from every layer, correlated so a threat is spotted before it becomes an incident. Evidence: what you monitor, and what raises an alert.
3. Respond — playbooks, escalation paths and the authority to contain. Evidence: incident records and the decisions taken at each step.
4. Recover — services and data restored from copies an attacker could not reach. Evidence: recent, successful recovery tests.
5. Comply — what you do, mapped to the frameworks you are assessed against, with the record kept current. Evidence: an audit trail rather than a folder of screenshots.

The cycle closes on itself. What you learn in response and recovery should change what you protect and how you detect it. An organisation that runs the loop routinely gets better at it. One that runs it only during an incident learns the same lessons twice.

04Six security pillars

A security programme needs a structure that stays stable while the tooling changes. Six pillars cover the ground most enterprises need, and each can be owned, measured and reviewed on its own.

The pillars are not separate budgets. Identity decisions shape network design, and data classification decides which applications need stronger controls. The value of the structure is that it gives every control a home and every gap a name.

Review each pillar against the pressures in the previous chapters, and ask the same question of each: if this failed tonight, what would we see, and who would see it?

05Zero trust: never trust, always verify

The perimeter model assumed that anything inside the network could be trusted. That assumption failed when users, applications and data left the building. Zero trust replaces it with a simpler rule: trust is never granted by location, and it is checked again on every request.

It is best understood as four checks applied continuously, not as a product you buy.

• Verify every user — strong authentication, with access decided by role, context and risk rather than by network.
• Verify every device — confirm device posture and health before it touches sensitive systems.
• Verify every application — authenticate services to each other, and enforce policy on every call rather than only at sign-in.
• Verify every session — watch behaviour once access is granted, and step up or revoke it when something looks wrong.

Where to start

1. Put single sign-on and MFA in front of everything, beginning with administrators and remote access.
2. Remove standing privilege. Grant elevated access for a task, with approval, and record the session.
3. Segment the network so that each workload reaches only what it needs.
4. Keep an inventory of devices, and refuse access from those you cannot assess.
5. Send identity and access events to the detection pipeline, so failed verification is seen as well as blocked.

The outcome is a smaller attack surface and stronger operational control. The discipline is treating trust as something re-earned, not something issued once.

06Security operations

Controls that nobody watches decay. Security operations is the practice of watching: collecting signals, deciding which ones matter, and acting before they become incidents.

• A security operations centre (SOC) — the people and process that monitor the estate, triage alerts and lead incident response. It can be in-house, outsourced or a mix, but its authority and escalation paths must be written down.
• SIEM — central collection and correlation of logs from identity, network, workloads and applications. Its value depends on coverage. A layer that sends no telemetry is a layer you cannot defend.
• Threat intelligence — knowledge of the techniques and indicators relevant to your sector and region, used to tune detection rather than to fill reports.
• Managed detection and response (MDR) — an external team that hunts and responds on your behalf, useful where full in-house cover is not practical.

Questions for your security operations

• Which systems send logs today, and which do not?
• How long are logs kept, and can they be searched quickly during an incident?
• Who can isolate a workload or disable an account, and do they need to ask first?
• When did you last run an incident exercise, and what changed afterwards?

The benefits are practical: faster detection, faster response, less downtime, and an operations record that doubles as compliance evidence.

07Data protection and recovery

Backups are the last line of defence, and attackers know it. A recovery plan that assumes the backups will be intact is a plan written for a different threat.

The foundation

• Encrypt data at rest and in transit, with keys under your custody and every use of them logged.
• Back up by the 3-2-1 rule: three copies of the data, on two different kinds of media, with one copy off-site.
• Recover to objectives the business has agreed for each service, not to a single target for everything.
• Validate by restoring, regularly, and recording the result.

What ransomware changes

• Immutable backups — copies that cannot be altered or deleted for a set period, even by an administrator.
• Air-gapped recovery — at least one copy separated, logically or physically, from the production network and its credentials.
• DR automation — recovery run from orchestrated runbooks, so failover does not depend on who happens to be on shift.
• Business continuity planning — the order in which services come back, agreed before the incident rather than during it.

Set recovery point and recovery time objectives service by service with the business owners, and tier them. Not every workload needs the same protection, and paying for the strictest tier everywhere is how recovery budgets run out.

Then test. A recovery that has never been rehearsed is an assumption, and the first real test should not be the incident itself.

08Security and compliance, together

Security and compliance are often run as separate programmes, with separate teams and separate calendars. The result is familiar: controls built for security that nobody can evidence, and evidence assembled for an audit that says little about real security.

Treat them as one system. The controls you run for security are the controls a framework asks you to prove.

Which frameworks apply depends on sector and location.

Certification attaches to an organisation, its scope and its practices. No platform or provider can be compliant on your behalf. What good tooling can do is make controls enforceable and evidence automatic.

Making it continuous

• Risk management — a living register, tied to the controls that address each risk.
• Asset visibility — you cannot evidence a control over an asset you do not know you have.
• Policy enforcement — rules applied before a service is provisioned, so non-compliant configurations are never created.
• Audit readiness — an immutable record of who ordered, approved, changed and accessed what.
• Continuous monitoring — control checks that run all year, not in the quarter before an audit.

Done this way, compliance becomes a by-product of operating well rather than a project that interrupts it. The GCC compliance guide sets out the regional frameworks by country and sector.

09Shared responsibility

Most serious incidents happen in the gap where each party assumed another was covering it. In any cloud, private or public, responsibility splits three ways, and the split should be written down before anything goes live.

In an enterprise private cloud, one organisation often plays two of these roles. Central IT operates the cloud, and business units are its tenants. That makes the lines easier to blur, not easier to ignore. Name the team that holds each responsibility, particularly key custody, access approval and service configuration.

If a partner operates the cloud for you, some operator duties move to them. Agree in writing which ones, how you will see evidence that they are met, and what happens to your keys, logs and data if the arrangement ends.

Questions to settle before go-live

• Who holds the keys, and who can use them?
• Who approves privileged access, and where is it recorded?
• Who patches what, and who is told when a fix is released?
• Who is responsible to the regulator, for which systems?

The model Oasis Stack publishes for its own platform is set out on the security page.

10Where Oasis Stack fits

Oasis Stack runs above infrastructure you already own, on-premises or in a colocation facility you choose, and publishes it as services. Security in it is a function of the platform, not a product beside it. The relevant parts are specific.

• Governance, Security & Compliance module — adopted when needed: identity, policy and audit applied to every service the platform provisions, with policy enforced before provisioning and an immutable record of who ordered, approved, changed and accessed what.
• Key custody — keys held in OpenBao, backed by an HSM, or brought by you, and kept under your custody.
• Privileged access — a two-person rule for privileged actions, and every privileged session recorded in full.
• VirtueSuite — identity and access management: LDAP, SAML and single sign-on with Microsoft Entra and Google Workspace, privileged access and key custody controls.
• Observa — observability, including the wellness dashboard built on Grafana, Prometheus and Wazuh, with a feed to your SIEM.
• Integrations — API-first, connecting to the SIEM, ITSM and CMDB you already run.

What it does not do is certify you. Controls are enforced and evidence is recorded as the platform runs, but assessment and certification remain the organisation’s own.

You can run it with your own teams or have the Oasis Stack team operate it for you under a support contract, with support in three layers (L1, L2 and L3), and there is no lock-in to any infrastructure vendor. The governance model is the one enforced in production on YallaCloud, the CloudHost group’s public cloud. See the Governance module and the operating model for the detail.