Skip to content
HACKTECH

Response and readiness

Incident response that contains the attacker without destroying the evidence of how they got in.

When an intrusion is under way, Hack Tech works it with you from triage through containment, forensic investigation, eradication and recovery, mapped to NIST SP 800-61 Revision 3. The same people run our penetration tests, where the job is to turn one foothold into domain admin, the backup console or the customer database. We read the evidence for those moves, so the report names the way in and every system reached from it.

Under attack right now?

Call +972 52 613 9179
Priority
Active incidents go to the front of the queue; say it is an incident when you call or write
First step
Triage begins on the first call, remotely, before any paperwork
Next step
Hands-on work starts remotely as soon as a short written authorisation is signed

Have this to hand when you call

  • Your name, your role and whether you can authorise work on the affected systems
  • What you saw, where and when (alert text and screenshots help)
  • What has been done since: anything switched off, reimaged, reset or deleted
  • Whether personal data, payments or production systems are involved
  • Who else knows: your insurer, counsel, IT provider or a regulator

Missing some of it? Call anyway. If your email may be compromised, phone rather than write, and keep the conversation off systems the attacker may be reading. Your on-call team's own checklist is the first hour of an incident.

How a response runs

Five phases, aligned to NIST SP 800-61 Revision 3 (opens in a new tab), published in April 2025. Rev. 3 moved incident response from the old four-phase cycle to a model built on the six CSF 2.0 Functions: Detect, Respond and Recover are the response itself, while lessons learned feed improvement continuously instead of waiting for the end. Timings are typical, not promises: a contained mailbox compromise can close in days, while a domain-wide ransomware recovery runs for weeks.

  1. Detect and triage

    First hourNIST CSF 2.0: Detect (DE.AE) · Respond (RS.MA)

    On the triage call we separate what is known from what is feared, decide what must be preserved before anything else changes, and agree the first containment moves before anyone hangs up. Your team's side of this hour lives in the first-hour checklist.

    What we do

    • Pin down the facts: what was seen, on which systems, by whom and when. Record every timestamp in both local time and UTC from the start.
    • Classify the incident and set a working severity, which decides who is woken now and what can wait until morning.
    • Identify the evidence that expires first (volatile memory, short-retention identity and cloud logs, EDR telemetry) and talk your team through capturing it without destroying it.
    • Pause the automation that erases trails: scheduled reimaging, account clean-up jobs, log rotation and auto-remediation on affected systems.
    • Agree the working structure: your incident lead, our responder, counsel where needed, and a channel that does not run through accounts the attacker may hold.
    • Flag the clocks that may already be running (regulators, insurer, card schemes and customer contracts) so nobody discovers a deadline on day three.

    You hold at the end

    • Working classification and severity
    • Evidence-capture list with owners
    • Agreed first containment moves
    • Authorisation and scope for hands-on work

  2. Contain

    Hours 1 to 24NIST CSF 2.0: Respond (RS.MI, RS.CO)

    Containment buys time. Every move is weighed against the evidence it would destroy, the business it would stop and what it tells the attacker. An intruder who notices the response too early may dig in deeper or speed up.

    What we do

    • Choose between quiet and immediate containment: observe while scoping when the attacker is passive, cut access at once when data is leaving or encryption is spreading.
    • Isolate affected hosts and segments at the network layer, keeping machines powered for analysis, and block confirmed attacker infrastructure at egress and DNS.
    • Revoke sessions and refresh tokens for compromised identities, not only passwords: a reset alone leaves stolen sessions working.
    • Protect the recovery path first: take backups and backup consoles out of the attacker's reach and rotate the credentials that administer them.
    • Extend visibility to hosts that had none, using your EDR where it exists, so the attacker's next move is recorded as it happens.
    • Forward the logs that matter to storage the attacker cannot alter, and raise retention before default windows expire.
    • Prepare holding statements and the internal brief with counsel, saying only what the evidence confirms so far.

    You hold at the end

    • Containment log: every action, its time, who approved it and what it changed
    • Evidence preserved with hashes and chain-of-custody records
    • Interim brief for leadership, counsel and insurer

  3. Investigate and eradicate

    Days 1 to 7NIST CSF 2.0: Respond (RS.AN, RS.MI)

    Forensic analysis answers the questions everyone will ask later: how they got in, what they touched, what they took and whether they are still there. Eradication waits for those answers and then happens in one coordinated move, because partial clean-ups only teach an attacker which footholds you have found.

    What we do

    • Build one timeline from disk, memory, identity, cloud, mail and network evidence, normalised to UTC.
    • Establish the initial access vector and every persistence mechanism: new accounts, OAuth grants, scheduled tasks, services, web shells, mailbox rules and cloud keys.
    • Determine data access and exfiltration from logs and artefacts, and record where the logs run out: both drive your notification decisions.
    • Hunt across the estate for the same indicators and behaviours, so one cleaned host does not hide three that were missed.
    • Plan eviction as a single event: credentials rotated (service accounts and the Kerberos krbtgt account included where Active Directory was reached), persistence removed and the entry point closed at the same moment.
    • Rebuild rather than clean any host whose integrity cannot be demonstrated.

    You hold at the end

    • Evidence-backed attack timeline
    • Root cause and initial access finding
    • Data-impact assessment for counsel
    • Indicators of compromise and detection rules for your tooling

  4. Recover

    Days to weeksNIST CSF 2.0: Recover (RC.RP, RC.CO)

    Restoration follows dependencies, so a system comes back only after the services it relies on, and each is verified clean before it rejoins the network. NIST's current guidance notes that recovery from modern incidents often takes weeks or months, so the restoration plan sets an order of work and an owner for every stage.

    What we do

    • Sequence restoration by dependency: identity and DNS, core infrastructure, backups, then line-of-business systems.
    • Restore from copies verified to pre-date the intrusion, and scan restored data before it is trusted.
    • Record every restoration as it happens: who restored what, from which copy and when. For medium and high security level databases, Israel's Data Security Regulations require the incident record to name who performed each restoration and what was restored.
    • Harden while rebuilding: MFA where it was missing, privileged accounts separated from daily ones, exposed management interfaces closed.
    • Watch for re-entry against the investigation's indicators for an agreed period after systems return.
    • Declare the end of recovery against criteria agreed in advance, so everyone knows when the incident is formally closed.

    You hold at the end

    • Restoration plan with order of work and owners
    • Clean-state verification for restored systems
    • Facts pack to support notifications
    • Formal end-of-recovery declaration

  5. Learn

    Post-incident reviewNIST CSF 2.0: Identify (ID.IM)

    Improvements are logged with an owner as soon as they surface during the response, so none waits for the review. The post-incident review then turns that log into dated work and records when each item is done.

    What we do

    • Run a blameless review with everyone who touched the incident, soon after closure while memory is fresh.
    • Compare what happened with what the plan said would happen, and record every gap, delay and workaround.
    • Map the attack to MITRE ATT&CK techniques and check which detections should have fired, and why they did not.
    • Turn findings into a remediation backlog in which every item has an owner and a due date.
    • Update the response plan, playbooks and contact lists, and schedule a tabletop exercise that replays this incident.
    • Scope a targeted penetration test of the entry point and the path the attacker used, to run once fixes land.

    You hold at the end

    • Final report: executive summary and technical detail
    • Lessons-learned register with owners and dates
    • Updated plan and playbooks
    • Detection improvements mapped to ATT&CK

Five ways to bring us in, during an incident or before one

Call for emergency response when an incident is under way. Arrange the other four in advance: a retainer gets the paperwork signed before you need it, a readiness assessment finds the gaps in your logging, backups and plan, a tabletop exercise rehearses the decisions, and a compromise assessment checks whether someone is already inside.

Emergency response

For an incident that is happening now: the five phases above, worked with your team from triage to a formal close.

Best for: Confirmed or strongly suspected compromise: encryption spreading, data leaving, an attacker in a mailbox or cloud account, or a ransom demand on screen.

What happens

  • Triage: what you are seeing, what is at stake, what to preserve and what to stop doing.
  • A short authorisation and scope, so we can act on your systems lawfully and without delay.
  • Remote evidence collection and containment guidance.
  • Written status updates for leadership, counsel and your insurer, with unknowns stated as unknowns.
  • Investigation, eradication and recovery support through to a formal close and a post-incident review.

You receive

  • Evidence-backed incident timeline and root cause
  • Data-impact assessment to support notification decisions
  • Final report with an executive summary and technical appendix
  • Prioritised hardening and detection backlog

Incident response retainer

Terms, authorisations and onboarding agreed before anything goes wrong, so when you call, the paperwork is already signed and the responders already know your environment.

Best for: Teams that would rather not negotiate a contract during an outage, and anyone whose board, insurer or enterprise customers ask who they would call.

What happens

  • Contract, authorisation templates and data-handling terms agreed and signed in advance.
  • Onboarding: your environment, critical systems, log sources, contacts and escalation paths documented with us.
  • An agreed, tested route to the responders that does not depend on your own email.
  • Readiness work across the term where you want it: tabletop exercises, compromise assessments, plan reviews.
  • Periodic review of the onboarding pack, so it describes the environment you actually run.

You receive

  • Signed terms and pre-approved authorisation
  • Onboarding pack: environment summary, contacts, log inventory
  • Agreed escalation and communication plan
  • Readiness activities as agreed in the retainer

Readiness assessment

A review of whether you could detect, contain and recover from a serious incident today (logging, identity, backups, people, plan and legal duties), measured against NIST SP 800-61r3 and the reporting rules that apply to you.

Best for: Organisations writing or refreshing an incident response plan, renewing cyber insurance, or answering security questionnaires from enterprise customers.

What happens

  • Interviews with IT, security, legal, communications and leadership to map who decides what, and how fast.
  • Review of your plan, playbooks, contact lists and the conditions in your insurance policy.
  • Technical checks on log sources and retention, time synchronisation, backup isolation and restore evidence, and privileged access.
  • Gap analysis against SP 800-61r3 recommendations and the notification duties in the GDPR, Israeli privacy law and your contracts.
  • A readout workshop that agrees priorities, owners and dates.

You receive

  • Readiness findings by area, rated by impact
  • Prioritised gap list with effort and owner
  • Drafted or marked-up plan and playbook improvements
  • Log source and retention inventory

Tabletop exercise

A facilitated rehearsal of a realistic incident, built from your architecture, your suppliers and the attacks your sector actually faces, and run with the people who would make the decisions.

Best for: Leadership teams and technical responders who have a plan but have never had to use it under pressure.

What happens

  • Scenario design with a small planning group, who choose the weak points the exercise will test.
  • Separate technical and executive tracks, or one combined session where decisions cross between them.
  • Injects that force the hard calls: whether to pay, when to notify, what to tell customers, who can take production offline.
  • Observation of decisions, escalation and communication against what your plan says should happen.
  • A hot debrief at the end of the session, followed by a written report.

You receive

  • Exercise report with observed strengths and gaps
  • Decision log from the session
  • Recommended plan changes with owners
  • Scenario pack you can rerun internally

Compromise assessment

A hunt for evidence that someone is already inside. Commission one when something feels wrong but nothing has fired, or before an acquisition, a funding round or a major launch.

Best for: Organisations after a near miss, an alert that was never explained, a breach at a supplier, or due diligence on a company being acquired.

What happens

  • Telemetry collected from endpoints, identity, cloud control planes, email and network sources across an agreed scope.
  • Hunting for known indicators and, more importantly, attacker behaviour: unusual authentication, persistence, lateral movement and data staging.
  • Identity configuration reviewed for backdoors: rogue OAuth applications, federation changes, dormant privileged accounts.
  • Immediate escalation into emergency response if active compromise is found.
  • A readout with evidence for every conclusion, and a plain statement of what could not be assessed.

You receive

  • Assessment report: findings, evidence and confidence
  • Visibility gaps that limited the assessment
  • Hardening and detection recommendations
  • Hunting queries and indicators handed to your team

Six incidents, and the moves that matter first

Each has a different first move and a different piece of evidence that disappears if nobody protects it. Open the one you are facing; its reporting clock may already be running.

Ransomware

Systems encrypted, a note on screen, and often a threat to publish stolen data as well. The decisions of the first hours outweigh almost everything that comes later: what to isolate, what to keep powered, whether the backups are still clean.

How it usually shows up

  • Files renamed with an unfamiliar extension and a ransom note in shared folders
  • EDR alerts for mass file modification, deleted volume shadow copies or security tools being disabled
  • Backup jobs failing, or backup consoles accessed and retention changed in the days before

First moves

  • Isolate affected segments at the network layer, and keep encrypted machines powered on for memory capture.
  • Take backups and their management consoles off the network and rotate the credentials that administer them.
  • Disable the accounts and tokens used in the attack, starting with domain and cloud administrators.
  • Preserve the ransom note, the negotiation portal address and any attacker messages, and do not reply.
  • Bring in your insurer and counsel before anyone engages a negotiator or discusses payment.

Preserve before anyone cleans up

  • Memory and disk images from the first affected host and a sample of encrypted ones
  • Domain controller security logs, EDR telemetry, and VPN or remote-access logs
  • Firewall and proxy records of large outbound transfers in the days before encryption
  • The ransom note, malware samples and any post on the group's leak site

Avoid

  • Wiping and reimaging before images are taken, which destroys the evidence of whether data left.
  • Contacting the attackers yourselves; negotiation and sanctions screening belong with specialists.
  • Restoring from backup before you know when the intrusion began, and therefore which copies are clean.

Reporting clock

The GDPR defines a personal data breach to include loss and alteration of data, not only theft, so encrypted systems holding personal data are in scope even if nothing left. Where the GDPR applies, Article 33 gives the controller 72 hours from becoming aware to notify the supervisory authority, unless the breach is unlikely to put individuals at risk. In Israel, the Data Security Regulations require a severe security incident to be reported to the Privacy Protection Authority immediately, and Amendment 13 to the Privacy Protection Law, in force since 14 August 2025, strengthened the Authority's enforcement powers. Your insurer's notice window is a separate clock. More by regime on the compliance page.

Orientation, not legal advice: confirm deadlines with counsel, because duties depend on your sector, your data and where the affected people are.

Related services:Network & infrastructure testingRed team & purple teamSocial engineering assessment

Business email compromise

A mailbox taken over, typically through a phishing page that captured the session along with the password, and used to redirect payments, harvest data or phish your customers from an address they trust.

How it usually shows up

  • Inbox rules that forward, move or delete messages mentioning invoices, payments or security
  • Sign-ins from unfamiliar countries or hosting providers, often just after an MFA prompt the user approved
  • A supplier or customer asking about bank details you never changed

First moves

  • If money moved, call your bank's fraud team first and ask for a recall. Recalls get harder with every hour.
  • Reset the password, revoke all sessions and refresh tokens, and review the registered MFA methods.
  • Remove malicious inbox rules, forwarding and delegates, and check for OAuth applications the attacker consented to.
  • Search for phishing sent from the account and warn the people who received it.
  • Export sign-in and audit logs now: Microsoft Entra ID keeps sign-in logs for seven days on the Free tier and 30 days on P1 and P2, Microsoft 365 Audit (Standard) keeps the unified audit log for 180 days by default, and the intrusion may have started earlier than anyone noticed.

Preserve before anyone cleans up

  • Unified audit log and sign-in logs for the affected identities
  • Message traces for the inbound phishing and for mail sent from the compromised account
  • Inbox rules, forwarding, delegates and app consents exactly as they were found
  • Payment instructions, invoices and the email threads around them

Avoid

  • Deleting the attacker's rules or messages before they are exported: they show intent and reach.
  • Relying on the user's memory of which prompts they approved; the logs are better witnesses.

Reporting clock

Attacker access to a mailbox is usually a personal data breach, because inboxes are full of other people's details. Where the GDPR applies, the Article 33 clock runs 72 hours from awareness, and Article 34 adds notice to the individuals themselves when the risk to them is high. In Israel, assess the incident against the Data Security Regulations' definition of a severe security incident, which must be reported to the Privacy Protection Authority immediately. If money moved, the bank's recall window is the least forgiving clock of all. See the compliance page.

Orientation, not legal advice: confirm deadlines with counsel, because duties depend on your sector, your data and where the affected people are.

Related services:Social engineering assessmentSecure development trainingCloud configuration review

Leaked cloud credentials

An access key in a public repository, a CI log or a container image (or a stolen developer session), and an attacker holding exactly the permissions that credential carried.

How it usually shows up

  • A secret-scanning alert, a provider abuse notice or a sudden bill for resources nobody launched
  • API calls from unfamiliar networks, or activity in regions you do not use
  • New IAM users, access keys, roles or trust relationships that nobody requested

First moves

  • Deactivate the exposed key rather than deleting it, then issue a replacement through your normal pipeline. Deactivation can be reversed if production still depends on the key, and the key keeps its last-used record.
  • Pull the control-plane logs for that identity immediately: AWS CloudTrail event history, for example, covers only the past 90 days of management events.
  • Map everything the credential could reach, then everything it actually touched: storage reads, snapshots, new identities, policy changes.
  • Look for persistence the attacker created: extra keys, roles trusting outside accounts, new functions, OAuth apps and compute you are now paying for.
  • Remove the secret from repository history and build artefacts, not only from the latest commit.

Preserve before anyone cleans up

  • CloudTrail, Azure Activity Log or Google Cloud Audit Logs for the identity and period
  • Data-access logs for storage and databases, where they were enabled
  • The repository, pipeline log or image where the secret was exposed, with timestamps
  • IAM state as found: users, keys, roles, policies and trust relationships

Avoid

  • Rotating and moving on: rotation stops future use but says nothing about what already happened.
  • Treating CloudTrail event history as complete: it shows management events only, so object reads appear only if a trail or event data store was recording data events.

Reporting clock

Whether a clock starts depends on what the credential could reach. If it could read personal data, treat the incident as a breach until logs show otherwise. Where the GDPR applies, controllers have 72 hours from awareness under Article 33, and a processor must tell its controller without undue delay. If you host customer data, your customers' own clocks may depend on how quickly you tell them. In Israel, a severe security incident goes to the Privacy Protection Authority immediately. See the compliance page.

Orientation, not legal advice: confirm deadlines with counsel, because duties depend on your sector, your data and where the affected people are.

Related services:Cloud configuration reviewApplication security auditThreat modelling

Web shell on a public server

A script planted on an internet-facing server that gives the attacker a command line inside your network. It usually gets there through an unpatched application, an upload feature or a vulnerable plug-in.

How it usually shows up

  • Unexpected script files in web directories, often named to look legitimate or with altered timestamps
  • The web server process spawning shells, scripting engines or network tools
  • Repeated requests to one obscure file from a handful of addresses, with unusual parameters

First moves

  • Block inbound access to the affected application at the load balancer or firewall, and keep the host running.
  • Capture memory, the web root, configuration and logs before anyone deletes the file.
  • Identify the vulnerability used and check every other server running the same software or version.
  • Trace which commands ran and where the attacker went next: a web shell is usually a beachhead, not the goal.
  • Rotate credentials stored on or reachable from the server: database passwords, API keys, service accounts.

Preserve before anyone cleans up

  • Web server access and error logs, including every request that touched the shell
  • A hashed copy of the web root and application directories
  • Process lists, network connections and memory from the running host
  • Database logs, if the application held database credentials

Avoid

  • Deleting the web shell before it is collected: its contents and timestamps are evidence.
  • Patching and declaring victory; the attacker may already be beyond the server.

Reporting clock

If the server, or anything it could reach, processes personal data, treat the incident as a potential breach from discovery. Where the GDPR applies, the Article 33 clock of 72 hours runs from awareness, and the information may be provided in phases when not everything is known yet. In Israel, for a database at high security level the Data Security Regulations count any unauthorised use of data as a severe security incident, reportable to the Privacy Protection Authority immediately. See the compliance page.

Orientation, not legal advice: confirm deadlines with counsel, because duties depend on your sector, your data and where the affected people are.

Related services:Web application testingWebsite security auditNetwork & infrastructure testing

Insider or departing employee

Someone with legitimate access who used it for something else: copying customer lists before leaving, selling access or sabotaging systems. The technical work is familiar; the legal and HR handling decides whether the findings can be used.

How it usually shows up

  • Bulk downloads, syncing to personal cloud storage or mass forwarding to a private address, often in the weeks before a resignation
  • Access to systems or records outside the person's role, or at unusual hours
  • USB storage, printing spikes or large archive files on a work device

First moves

  • Involve HR and counsel before anyone confronts the person or opens their mailbox. Monitoring an employee is legally sensitive in Israel and the EU.
  • Preserve devices, accounts and the mailbox in place; do not reassign the laptop or delete the account at departure.
  • Restrict access quietly and proportionately while evidence is preserved, if continued access risks further harm.
  • Review everything the person could reach across SaaS, cloud, source code and shared credentials, and rotate whatever was shared.
  • Establish what left, where it went and whether it has been used, with forensic soundness fit for a tribunal or court.

Preserve before anyone cleans up

  • Forensic images of the work laptop, and of mobile devices where policy allows
  • Cloud storage, email and DLP logs, including sharing and download events
  • Badge, VPN and authentication records for the relevant period
  • Employment contract, acceptable use policy and any monitoring notices the person acknowledged

Avoid

  • Letting IT browse the person's mailbox informally, which can taint the evidence and breach privacy law.
  • Wiping or reissuing devices at offboarding while a concern is open.

Reporting clock

Data taken by an insider is still a breach. Israel's Data Security Regulations define a severe security incident to include use of data in excess of authorisation (any such use in a high security level database, or of a substantial part of a medium security level one), and severe incidents must be reported to the Privacy Protection Authority immediately. Where the GDPR applies, the 72-hour Article 33 clock runs from awareness. Employment and privacy law also shape how you may investigate, so take advice early; see the compliance page.

Orientation, not legal advice: confirm deadlines with counsel, because duties depend on your sector, your data and where the affected people are.

Related services:Database security auditThreat modellingCloud configuration review

Dependency or vendor compromise

The breach starts somewhere you do not control: a poisoned package or build tool, a compromised SaaS provider, a managed service provider's remote access, or a vendor's stolen tokens into your tenants.

How it usually shows up

  • A vendor breach notice, a security advisory for a package you use, or reports of a compromised update
  • Build servers or developer machines connecting to unfamiliar hosts after an update
  • Activity from a vendor integration in your SaaS or cloud tenants that does not match its purpose

First moves

  • Inventory exposure: which versions, systems, integrations and credentials the vendor or package could reach.
  • Revoke or rotate the integration's tokens, API keys and OAuth grants, and restrict it until the vendor's investigation is credible.
  • Roll back to a known-good version and rebuild artefacts from clean sources rather than patching in place.
  • Hunt for the indicators the vendor or researchers have published, and for behaviour beyond them.
  • Ask the vendor for specifics in writing: timeline, affected data, indicators and what they need from you.

Preserve before anyone cleans up

  • Lockfiles or a software bill of materials showing which versions ran where, and when
  • Build and CI logs, artefact hashes and package-manager caches
  • Logs of the vendor integration's activity in your tenants
  • Vendor notices, advisories and your correspondence with them

Avoid

  • Waiting for the vendor's final report before acting on your own exposure.
  • Assuming the vendor's scope statement covers your environment; check it against your own logs.

Reporting clock

If the vendor processes personal data for you, Article 33(2) of the GDPR obliges it to notify you without undue delay. Treat that notice as the start of your own assessment, not the end of its investigation. If you are the vendor, your customers' clocks may depend on how fast you tell them. In Israel, a severe security incident must be reported to the Privacy Protection Authority immediately, whoever caused it. Contracts often add their own windows; see the compliance page.

Orientation, not legal advice: confirm deadlines with counsel, because duties depend on your sector, your data and where the affected people are.

Related services:Application security auditThreat modellingCloud configuration review

What to have in place before an incident

Five areas decide how long an incident lasts and how much of it you can prove afterwards. Most items here are configuration and decisions rather than projects, and a readiness assessment checks them against your own environment.

Logging and retention

Investigations are limited by the logs nobody kept. Decide now what you would need to answer how they got in and what they took.

  • Identity provider, VPN and remote-access logs centralised and kept beyond their default windows
  • Cloud control-plane logging on in every account and region, with data-access logging for sensitive stores (AWS CloudTrail event history alone holds only 90 days of management events)
  • Microsoft 365 or Google Workspace audit logging confirmed on, with retention checked against your licence: Microsoft 365 Audit (Standard) keeps 180 days by default
  • Endpoint telemetry on servers as well as laptops, including the ones nobody likes to touch
  • Clocks synchronised across systems, so a timeline can be built without guesswork
  • Logs shipped to storage that administrators of the logged systems cannot alter or delete
  • For Israeli databases at medium or high security level, access-monitoring records kept for at least 24 months, as the Data Security Regulations require

Identity and access

Serious incidents tend to become identity incidents: the fewer standing privileges exist, the less an attacker inherits.

  • Phishing-resistant MFA for administrators and remote access, with an exceptions list someone actually reviews
  • Privileged accounts separate from daily ones, and break-glass accounts documented, monitored and tested
  • An inventory of service accounts, API keys and OAuth applications, each with an owner
  • A rehearsed way to revoke sessions and tokens for one user, a group or the whole tenant
  • Offboarding that removes access everywhere on the day someone leaves, SaaS and shared credentials included

Backups and recovery

Backups turn a crisis into an incident, but only if the attacker cannot reach them and you have proved they restore.

  • At least one copy offline or immutable, administered with credentials that do not live in your main directory
  • Scheduled restore tests with the time taken recorded, not only job-success emails
  • A restoration order for identity, core infrastructure and revenue systems, agreed before it is needed
  • Retention long enough to restore from before an intrusion that went unnoticed for weeks
  • Restoration documented as it happens; for medium and high security level databases, Israel's Data Security Regulations require a record of who restored and what was restored

People and process

Plans fail at the handovers: who decides, who is told, and who may switch something off at two in the morning.

  • A short response plan with named roles and deputies, kept where an outage cannot reach it
  • Decision rights written down: who can isolate production, take systems offline or call in outside help
  • Out-of-band contact details for responders, leadership, counsel, insurer and key suppliers
  • Playbooks for your likeliest incidents: ransomware, mailbox compromise, exposed cloud keys
  • A tabletop exercise at least once a year, with its actions tracked to closure
  • Regular incident reviews: Israel's Data Security Regulations set them at least annually for medium and at least quarterly for high security level databases

Questions about working an incident with us

Remote and on-site work, ransom demands, insurers, evidence handling, retainers, and what you hold once the incident is closed.

Can you respond remotely, or do you need to be on site?

Most first-day work is remote: triage, evidence collection and containment guidance run over a call and a secure channel, and remote collection reaches cloud and endpoint evidence sooner than anyone could travel. On-site work is agreed for each incident, usually for isolated networks, physical media, operational technology, or a leadership team that wants a responder in the room; tell us on the call where the affected systems are.

What do you need from us on the first call?

Someone who can authorise work on the affected systems, and ideally your incident lead, because the first containment moves and the authorisation for hands-on work are agreed on that call. If personal data may be involved, bring counsel in early. The list at the top of this page covers the facts to have ready; call with whatever you have.

Do you negotiate with ransomware groups?

No. We do not negotiate payments ourselves. When a ransom demand is on the table we coordinate with specialised negotiators, your insurer and your counsel, and give them what the decision needs: whether backups are viable, what data actually left, and whether the attacker's claims stand up. Payments can also carry sanctions risk, which is one more reason the decision belongs with counsel. The US Treasury's Office of Foreign Assets Control published an updated advisory on that risk in September 2021.

We have cyber insurance. Does that change who we call?

Read the policy before you need it: many require you to notify the insurer before engaging responders, and some require firms from their panel. Under attack, call the insurer's breach line and your responder in parallel. Triage does not have to wait for the claim. Whether a given policy covers our work depends on its terms and panel; tell us what your insurer says and we will work within its conditions, including alongside a panel firm.

How do you keep evidence forensically sound?

We collect with read-only methods, hash every image and export at the moment of collection, and keep a chain-of-custody record: who collected what, when, from where, and every hand it passed through. Analysis runs on copies, never on originals. If the incident may end in litigation, an employment dispute or a police complaint, say so on the first call so collection meets that standard from the start.

What happens after the incident is closed?

You receive a final report with an executive summary and a technical appendix, a remediation backlog with owners, and the indicators and detections built during the investigation. We run the post-incident review with your team. Once fixes land, a targeted penetration test of the entry point, scoped as its own engagement, checks that it is closed. A tabletop exercise can then replay what happened, and a retainer puts terms in place before the next call.

How do retainers work if you do not publish prices?

Each retainer is quoted after a short scoping conversation, because the price depends on what goes into it: the environment we onboard, the readiness work included (tabletops, compromise assessments, plan reviews), how often the onboarding pack is reviewed and how unused time is applied. Every retainer includes signed terms and authorisation templates, an onboarding pack and a tested route to the responders, as described under Incident response retainer.

How is incident response different from a penetration test?

A penetration test asks how someone could get in; incident response establishes how someone did. Each feeds the other: an investigation's root cause tells a test where to dig, and a test that proves a flaw exploitable is often the cue for a compromise assessment to check whether someone got there first. Penetration testing and the scoping call cover the testing side.

Can you help with regulators and law enforcement?

We do not give legal advice, but we produce the facts that counsel and regulators ask for: a timeline, the data affected and the measures taken. Israel's Data Security Regulations, for example, require a report on the measures taken alongside notice of a severe security incident. We can brief your counsel, your data protection officer or law enforcement contacts on the technical findings in plain language.

What if we are not sure it is an incident at all?

Call anyway. A short triage conversation usually settles it: if the activity is benign, you have spent a few minutes; if it is an intrusion, memory and short-retention logs are captured before they expire. When the answer is 'something is wrong but we cannot see what', that is the job of a compromise assessment.

Will you take over from our IT provider or internal team?

We work alongside your internal team and your managed service provider rather than replacing them: they know the environment, and we bring investigation and containment. If the provider's own access may be the way in, we say so plainly and advise how to restrict it while the investigation runs.

The checklist, breach write-ups, reporting rules and news to read next

The first-hour checklist is for whoever is on call; the other three are for planning.

Standards and rules cited on this page

Test the plan while nothing depends on it.

A readiness assessment checks your logging, backups, identity controls and reporting duties against your environment; a tabletop exercise puts your leadership and responders through a realistic incident and records where decisions stall.

Talk to a responderAll services