Skip to content
العربية

Service 05 · Security

Controls that exist, not controls that are described.

What matters is what the systems enforce. The work is closing the distance between the written policy and the running configuration — across identity, network, applications, cloud and data — and being able to show with evidence that it is closed.

Depth is a distance

Defence in depth is not layers stacked on a slide. It is boundaries, each with one controlled crossing, and the crossings deliberately unaligned — so reaching data means traversing rather than walking in. Every crossing here is an identity check.

The control set, by capability family

Seven families, grouped by what they protect rather than by product category, because a control is only meaningful against the thing it is holding shut.

Security architecture and engineering

  • 01.1Security architecture reviewed at design time, not at go-live
  • 01.2Control mapping against the framework the organisation uses
  • 01.3Gap assessment with a remediation order that is kept
  • 01.4Security in the delivery pipeline rather than after it

Identity and access

  • 02.1Directory and federation design
  • 02.2Multi-factor and conditional access
  • 02.3Privileged access separation and review
  • 02.4Joiner, mover and leaver processes tied to the HR record
  • 02.5Access recertification with evidence

Network and infrastructure security

  • 03.1Endpoint protection, hardening and patch baselines
  • 03.2Segmentation between environments and functions
  • 03.3Remote access and third-party connections, scoped and monitored
  • 03.4Email and web filtering

Application, API and cloud security

  • 04.1Application security — authentication, session and data exposure
  • 04.2API security, authorisation and rate control
  • 04.3Cloud posture, guardrails and landing-zone policy
  • 04.4SAP authorisations aligned with identity outside SAP
  • 04.5Access control over what an AI system may read

Data protection

  • 05.1Classification, and controls that follow it
  • 05.2Encryption at rest and in transit, with key custody
  • 05.3Backup isolation and restore testing
  • 05.4Residency and cross-border transfer decisions

Vulnerability, detection and response

  • 06.1Vulnerability and exposure management, prioritised by reachability
  • 06.2Log collection and correlation, reaching somewhere it will be read
  • 06.3Alerting tuned so that people still read it
  • 06.4Incident response runbooks and rehearsal
  • 06.5Containment, eradication and recovery steps that are practised
  • 06.6Post-incident review that changes something

Resilience, governance and assurance

  • 07.1Operational resilience and recovery readiness
  • 07.2Evidence collection for audit
  • 07.3Third-party and supplier review
  • 07.4Security awareness aimed at the decisions people actually make

Four things running at once

  1. 01

    Know

    What exists, who can reach it, and which of that is deliberate.

  2. 02

    Reduce

    Close what is open without a reason. Most of the improvement is here, and it costs least.

  3. 03

    Detect

    Assume something gets through, and make sure it is visible when it does.

  4. 04

    Prove

    Evidence, so the control can be shown to work rather than asserted to.

Where an engagement usually starts

With identity, and with what is exposed. Those two answer most of the early questions — who can reach which system, and which of that was intended — and they are where the largest reduction in risk costs the least.

The work is then ordered by what the organisation most needs to protect: the systems that run the business, the data it would be damaging to lose, and the routes into both. Noble designs and engineers those controls, and where the client wants them operated as well, the managed-services team runs them.

Where it has to reach