A specialist security practice for regulated workloads.

A SOC that produces trustworthy signal.

Building a SOC is straightforward. Building one whose detections fire on the cases that matter, whose analysts trust the alerts, and whose runbooks survive staff turnover — that is engineering work. We design the SOC operating model and its detection content as code, anchored on the platforms you already run.

SOC architecture

Detection engineering as code

Detections are content. Content has a lifecycle: research, develop, test, deploy, tune, retire. We run that lifecycle as a software-engineering practice:

• Detection-as-code repositories — rules versioned in Git, peer-reviewed, deployed via CI to the SIEM/XDR.
• MITRE ATT&CK mapping — every detection labelled with the techniques it covers, gap analysis run against the matrix quarterly.
• Test fixtures — replayable attack-sample inputs that validate detection behaviour before promotion.
• Tuning loop — false-positive rate tracked per detection, with documented thresholds for tuning, retirement, or escalation to engineering.
• Coverage reporting — what we detect, what we don't, what the gaps mean for your risk picture.

Incident response

• Runbooks indexed by failure mode — not generic wiki pages, but procedures verified against the live system.
• On-call structure — tiers, escalation paths, rotation patterns, postmortem cadence.
• Tabletop and red-team exercises — quarterly drills that reveal what the runbooks haven't yet covered.
• Forensic readiness — pre-staged collection capability, chain-of-custody discipline, evidence retention aligned with regulatory hold requirements.

Threat hunting

Detections only fire on known patterns. Threat hunting closes the gap by hypothesis-driven investigation against the data you've already collected. We stand up a hunting practice with:

• A hunt-hypothesis backlog driven by threat intelligence and observed attacker behaviour.
• Documented hunt procedures, with queries, expected results, and findings published per hunt.
• A feedback loop into detection engineering — hunts that find something become detections.

Find it before someone else does — then close the loop.

Vulnerability discovery without remediation tracking is theatre. We run penetration tests, vulnerability scans, and purple-team exercises as engineering programmes: scoped, repeatable, with findings landed directly in your engineering team's bug queue and closure tracked to production.

Penetration testing

Every test is scoped to the question that justifies it. We work to PTES, OWASP, and NIST SP 800-115 methodology where relevant, but the deliverable is always findings your engineers can act on — not a pile of CVSS numbers.

Continuous vulnerability management

Point-in-time scans age fast. We design the programme as a continuous operating loop: scan, triage, route, fix, verify, report.

• Tooling. Greenbone (OpenVAS), Tenable Nessus, Qualys VMDR for infrastructure. Acunetix or Invicti for web DAST. Trivy and RHACS for container images.
• Asset coverage. Inventory-driven, not scan-target-driven. We integrate with your CMDB / Nautobot / cloud inventory so coverage gaps surface.
• Triage. Findings routed to the team that owns the asset, with SLAs by severity. False-positive feedback closes the loop on tuning.
• Remediation tracking. Open / fixing / fixed / risk-accepted, with explicit owners and dates. No "open forever" findings.
• Risk-acceptance discipline. Documented, time-boxed, with a re-review trigger. Audit-ready by default.
• Reporting. SLA compliance, mean-time-to-remediate, top recurring root causes — the metrics that drive engineering action, not vanity numbers.

Purple-team operating loops

The lab discipline that scales: blue team writes a detection, red team designs an attack that should trigger it, both sides watch the evidence together, gaps go into the engineering backlog. Then repeat — weekly, monthly, quarterly, depending on the scope.

Cisco data-centre security and segmentation done as engineering.

Network segmentation is where most regulated organisations have either over-promised and under-delivered, or built so much complexity that nobody dares change anything. We design segmentation as a tractable engineering problem — with desired state in Git, validation as code, and route-leak controls you can prove are working.

Cisco data-centre fabric

We design and operate Cisco Nexus 9000 fabrics with MP-BGP EVPN overlays and VXLAN tenant segments — the production pattern for modern multi-tenant data centres. Multisite EVPN/VXLAN with border gateways extends this across data centres for DR and active-active patterns.

• Nexus 9000 / NX-OS — spine-and-leaf topology, BGP underlay, MP-BGP EVPN overlay, VXLAN data plane.
• Multi-tenant segmentation — tenant VRFs per business unit, L3VNI / L2VNI mapping, anycast gateway, ARP suppression.
• Services VRF and route-leak controls — explicit, named prefix advertisement between tenant and services VRFs, with daily validation that only approved prefixes are visible across the boundary.
• Multisite design — border gateway placement, control-plane separation, traffic engineering across DCI.
• Nexus Dashboard & NDFC — controller-based operations for fleets where manual NX-OS doesn't scale.
• ACI / APIC — alternative model where application-centric policy is the right primitive.

GitOps-managed network state

The hardest part of multi-tenant fabrics is not building one — it's keeping the running configuration matched to a designed intent six months later. We treat network state as code:

• Nautobot as the network source-of-truth (devices, interfaces, IP plan, VRFs, prefixes).
• Oxidized for automated config backup with drift detection per device.
• Batfish for offline policy analysis — "if this change deploys, will the route-leak controls still hold?" answerable before the change ships.
• Daily validation jobs — checks for approved prefix visibility, denied prefix absence, route-map attachment, backup freshness. Failures alert the SOC.
• Ansible automation for the change path itself, with idempotent playbooks and reviewed pull requests as the entry point.

Perimeter, NAC, and micro-segmentation

Identity is platform, not application.

Most identity problems are not technology problems — they are platform-shape problems. We design identity as the boundary your platform is built around, not as an application your team integrates with after the fact.

Federation and SSO

Lifecycle and provisioning

• Directory of record. One authoritative source — HR system or Active Directory — with everything else downstream.
• SCIM provisioning. Joiner / mover / leaver flows automated end-to-end. No orphan accounts, no stale entitlements.
• Role and group governance. Roles modelled deliberately, not accreted. Reviews on a quarterly cadence with evidence captured automatically.
• Privileged access management. Time-bound, just-in-time elevation. Vault dynamic credentials for service-level access. Session recording for admin sessions where regulators require it.
• Service identities. Workload identity via SPIFFE/SPIRE or platform-native mechanisms (Kubernetes service accounts, AWS IAM Roles for Service Accounts, Azure managed identities).

Authentication and authorisation flows

• OIDC and OAuth2 — canonical for modern web and mobile applications, with token-exchange patterns for service-to-service.
• SAML — canonical for enterprise SaaS integrations.
• MFA strategy. Push (Duo, Auth0, Okta-style), TOTP for fallback, FIDO2 / passkeys where the regulator and user base allow.
• Step-up authentication. Context-aware elevation for sensitive operations (high-value transactions, admin actions).
• Authorisation. Fine-grained where it earns its keep — OPA / Rego, XACML, or platform-native ABAC. We don't over-engineer.

Zero-trust network access

For remote and partner access, we replace flat-VPN topologies with identity-bound application access:

• Cisco Secure Access or Zscaler Private Access for the ZTNA layer.
• Cisco Duo for device trust and MFA.
• Cisco Umbrella for DNS-layer protection and SaaS visibility.
• Integration with your IdP so policy is identity-driven, not subnet-driven.

Shift left in the pipeline. Shift right at runtime.

Application security is platform engineering with a security framing. We integrate SAST, SCA, SBOMs, image signing, policy gates, runtime security, and DAST as a coherent pipeline — not as a stack of bolt-on tools each fired by a different team.

Shift-left: pipeline-integrated security

Shift-right: runtime security

What the pipeline missed is what runtime has to catch. We deploy and tune the runtime layer to your environment, not to the vendor defaults:

• RHACS (StackRox) — admission policies, network baselines, runtime detection, image-risk gates. Integrated with SIEM/SOAR.
• Falco — eBPF-based runtime detection, useful where RHACS isn't deployed.
• Cisco Secure Workload — behavioural micro-segmentation for east-west traffic with policy as code.
• Pod security and admission control — Kubernetes Pod Security Standards, OPA Gatekeeper / Kyverno policies enforced at admission.
• Network policy — Calico / Cilium / Istio authorisation policies, tied to the segmentation model.

DAST programmes

Continuous web-application security testing against the deployed application — authenticated scans, scheduled re-runs, findings landed in the engineering team's bug queue with proof-of-fix retest:

• Acunetix or Invicti as the primary DAST platform — chosen for your stack and integration model.
• OWASP ZAP for self-service scans, with baseline and full-scan profiles wired into CI.
• API-aware scanning for REST, GraphQL, and SOAP APIs — OpenAPI-driven, schema-aware.
• Authentication recipes — OIDC, SAML, custom token flows. Your apps don't get to opt out of authenticated scans by being awkward to log in to.

AppSec assessments and threat modelling

• Architectural threat modelling for new applications and significant changes — STRIDE-style, focused on findings engineers can act on.
• Secure-design reviews at the right point in the SDLC — not too early to be speculative, not too late to be expensive.
• Secure-coding training tailored to your stack, with measurable improvement in PR-level findings post-training.

Evidence at the source. Audit as a side effect.

Most compliance programmes reconstruct evidence at audit time — an expensive, error-prone exercise that produces output that nobody trusts. We design the platform so that evidence is captured at the moment of action, in tamper-evident stores, available on demand. Audit becomes the side effect, not the project.

Control-framework mapping

We work with the frameworks your organisation reports against, mapping each control to the platform mechanism that actually implements it:

Evidence at the source

The shift from project-style compliance to continuous compliance:

• Git commits as change evidence. Signed commits with author and review trail are the evidence that a change happened, who approved it, and what reviewer comments resolved.
• GitOps reconciliation as configuration evidence. The desired state in Git, the reconciliation log in the cluster, and the running configuration on the device should all match — and the diff is the evidence either way.
• Pipeline outputs as security evidence. SAST, SCA, SBOM, signed images, policy decisions — captured at build time, attached to the image, queryable forever.
• Runtime audit logs. Vault audit log, RHACS event log, identity audit log, all forwarded to immutable storage with retention aligned to regulatory hold requirements.
• Operational evidence. Postmortems, change records, on-call logs, incident timelines — captured in your ticketing/wiki/SIEM with consistent metadata.

Audit-cycle support

• Readiness assessments ahead of formal audit, with gap remediation tracked to closure.
• Evidence-request facilitation — matching auditor information requests to the right source-of-truth, training your team to do this without re-engagement.
• Findings remediation — engineering-grade fixes for audit findings, not paperwork loops.
• Risk-acceptance register — documented exceptions with time-boxed re-review, accepted at the right authority level.

Reporting that matters

We build reporting your board, regulator, and engineering leadership all read:

• SLA compliance for vulnerability remediation, with the gap analysis between aspiration and reality.
• Mean-time-to-remediate by severity, by business unit, by application.
• Control-coverage heat-map against your chosen framework.
• Open audit findings, with owner, ETA, and the risk while open.
• Top recurring root causes — the metric that drives engineering investment.