- Zen IT Technologies
- Security Readiness & Response
Your ability to respond is built before you need it.
Security response is not something we add after an incident. We build the capability into the environments we manage: logging and retention, endpoint visibility, audit trails, recovery procedures, and the ability to query or deploy across the estate when something needs investigating.
When a new indicator of compromise is published, a dependency is found to be compromised, or an incident happens, the environment is already structured to answer the questions that decide the outcome. What is affected. What happened. What has to be contained. How you recover.
The problem
Most organizations discover their response capability during the incident.
The alert fires and the questions start immediately. Which machine. Which user. What did they touch. Was anything else using that credential. And underneath all of them, the one that actually decides the outcome: can we even find out?
The gaps are always the same, and always identified too late:
-
No forensic tooling in place.
Acquisition depends on physical access to a device that may be in another country.
-
Logs already gone.
Google Workspace, Microsoft 365, and source-control audit logs aged out on default retention while the incident was still being scoped.
-
No inventory to scope against.
Nobody can list which SaaS applications hold company data, or which service accounts exist.
-
No decision rights agreed.
The question of who can authorize taking production offline at 3 a.m. is being worked out during the incident.
-
Nothing written afterwards.
The incident resolves, and six months later a customer, auditor, or insurer asks what happened.
What we do
- Identity
- Endpoints
- SaaS
- Audit logs
- Evidence
-
Response capability, built in
Response readiness is part of running an environment properly rather than a separate product. Forensic tooling deployed across the fleet through the management platform, so evidence collection does not depend on physical access to a device. Audit-log retention extended beyond platform defaults. Detection engineering maintained against current attack patterns. Asset and identity inventory kept current, because scope determination depends on it.
-
Establish the baseline
We start by establishing what can actually be detected, investigated and recovered today: tooling coverage, log retention, inventory completeness, identity exposure, recovery capability and decision rights. The gaps become part of the remediation roadmap and are then maintained as the environment changes.
-
Response planning
Runbooks for the scenarios that actually occur: endpoint compromise, credential and session takeover, dependency compromise. Each with a containment sequence that preserves evidence rather than destroying it. Decision rights, escalation paths, and communication responsibilities agreed while everyone is calm.
-
Query and act across the estate
When an indicator of compromise is published, the questions are straightforward: which machines have it, do we hold the logs that would show it, can we query them, and can we deploy a check across the estate? In an environment we built, those capabilities are already in place. Scripts and queries can be deployed fleet-wide through the management platform, identity and audit data is already collected, and the inventory is current enough to scope against.
-
Business continuity and recovery
Response does not end at containment. Backup and recovery procedures, restore testing, and the continuity plan are part of the environment rather than a document produced when an auditor asks for one.
Where they apply, we build and run the environment against the requirements and controls of ISO/IEC 27001, ISO 22301 for continuity management, and ISO/IEC 27031 for ICT readiness. The same infrastructure that lets us understand what happened is the one that helps the business keep operating and recover.
-
Security Incident Response and Digital Forensics
Incident triage, containment, and coordinated response for endpoint, identity, and supply-chain compromise. Deployment and operation of forensic tooling across the fleet; audit-log acquisition and analysis across Google Workspace, Microsoft 365, and source control platforms. Root cause analysis and formal written incident reporting. Post-incident hardening, detection engineering, and remediation tracking.
-
Monitoring and Observability
Synthetic monitoring, uptime and endpoint checks, alert routing, and on-call escalation workflows. SIEM and telemetry pipeline configuration and maintenance.
Technical notes
Reading a fleet-wide detection spike
The shape of the spike identifies it faster than the file analysis does.
How it runs
-
Assessment.
A documented review of your current response capability, with the gaps ranked by what they would cost you during an incident.
-
Remediation.
Tooling deployed, retention extended, inventory built, detection engineered.
-
Planning.
Runbooks and decision rights agreed and written down.
-
Maintained.
Reviewed as the estate changes and as attack patterns change. A plan written once is a plan that will be wrong.
This is not an emergency service brought in only when something goes wrong. Readiness is maintained as part of the ongoing service, so when an incident occurs we are responding from an environment we already know and manage.
Proof
-
Forensic capability deployed before it was needed.
Technology company
Acquisition tooling rolled out fleet-wide through the existing management platform, so evidence collection never depends on physical access to a device, including for staff and contractors working from another country.
-
Audit log retention extended past platform defaults.
SaaS platform
Retention windows across identity, collaboration, and source-control platforms assessed against realistic investigation timelines, then extended where the default would have expired mid-investigation. Acquisition paths documented alongside them.
-
Detection rebuilt during a live campaign.
Technology company
Indicators from an active supply-chain campaign were turned into fleet-wide detection within the day, forensic collection was deployed across the estate, and the investigation produced a definitive assessment of exposure, delivered as a formal report.
-
A fleet-wide EDR malfunction contained and resolved with the vendor.
Technology company
An operating system update put the endpoint platform into a detection loop across the fleet, flagging components of the OS itself. The issue was triaged fleet-wide, an exclusion policy was engineered rather than applied per alert, and the fault was escalated to the vendor and tracked to a fixed release.
Client examples are anonymized by design. References are provided privately, on request, and with the client's consent.
Who this is for
Companies that would rather find out what they can investigate now than during an incident. Typically ahead of an audit, after a near miss, or when a customer security questionnaire asks a question nobody can answer.
Frequently asked questions
-
Do you take emergency incident work from companies you do not already work with?
No. Response is fast because we already have access, already know the identity model, and already manage the endpoints. Arriving cold during an incident removes all three advantages. If you are in an active incident and not a client, you need a dedicated response firm that can mobilize today.
-
What does a readiness assessment actually cover?
What you could investigate right now: forensic tooling coverage, audit log retention and acquisition paths, asset and identity inventory completeness, session revocation capability, and the decision-rights gaps that cost hours during a real incident. You get a written baseline and a prioritized remediation list.
-
How long should we retain audit logs?
Longer than the default, which is shorter than most people assume and varies by platform and license tier. Investigations routinely need to reach back weeks to establish when access began, so a thirty-day window frequently fails at the moment it matters. Know the retention period for each platform and extend it where necessary.
-
Is EDR enough on its own?
No. Detection is not investigation. EDR tells you something happened on an endpoint; establishing what was accessed, whether credentials were reused elsewhere, and what the blast radius was requires audit logs, inventory, and identity context that EDR does not hold.
-
Who writes the incident report?
We do, for environments we run. The report covers the timeline, entry vector, scope, data accessed, containment actions, root cause, and remediation status. It is written for leadership, customers, insurers, and auditors, with technical detail behind a plain-language summary.
Build response capability into your environment.
A 30-minute call with Jonny. We reply within one business day.