Skip to content

Security practices

Incident Response

How WebCastle identifies, contains and investigates security incidents, how affected customers are told, and how the response process is being formalised.

10 of 12 controls operating todayDomainOperatingReviewed 12 August 2026

At a glance

  • A monitored security mailbox is the route for reporting an incident.
  • A technical lead owns each incident from identification to review.
  • Affected customers are notified when their data or service is involved.
  • Formal documentation of the response plan is in progress.

Overview

WebCastle treats any event that may have compromised the confidentiality, integrity or availability of customer data or a customer service as a security incident. That includes suspected unauthorised access, credential exposure, malicious code, data corruption and significant unplanned outages with a possible security cause.

WebCastle responds to incidents today, and the sequence set out on this page reflects what actually happens: an engineer or a customer raises something, a technical lead takes ownership, the immediate risk is contained, the cause is investigated, the fault is fixed and service is restored, and the customer is told. What is not yet in place is the formal artefact — an approved written plan with named standing roles, agreed severity thresholds and notification templates. That documentation is being completed.

This distinction matters in procurement, so WebCastle states it plainly rather than implying a maturity it has not reached. Any timeframe mentioned below is an indicative good-faith target based on how WebCastle works, not a service level. Contractual notification obligations are governed exclusively by individual customer agreements.

How incidents are classified

Severity drives who is involved, how quickly, and whether customers are notified. Written thresholds are being formalised; the working definitions are below.

  • Critical

    Confirmed or strongly suspected unauthorised access to customer data, or a complete loss of a production service. Leadership is engaged immediately and affected customers are contacted as soon as there is something accurate to tell them.

  • High

    A significant vulnerability being actively exploited, exposure of credentials with production reach, or a partial outage affecting customer users. Response begins immediately and continues until the risk is contained.

  • Medium

    A security weakness with limited or no evidence of exploitation, or a contained issue affecting a non-production environment. Handled through the normal engineering workflow with a defined owner and deadline.

  • Low

    Findings with minimal practical risk, such as informational scanner output or hardening opportunities. Logged and scheduled into routine maintenance.

The response lifecycle

The sequence WebCastle follows. Timeframes shown are indicative good-faith targets, not commitments; contractual terms are set in your customer agreement.

  1. Identification

    Immediate

    An event is recognised as a possible incident. Sources include cloud provider native alerts, availability and error signals, a report from a customer or researcher, or an observation by an engineer during routine work. Anyone at WebCastle can raise a suspected incident, and reports from outside reach the security mailbox directly. The first action is always to record what was seen, when, and by whom.

  2. Assessment

    Within hours

    A technical lead takes ownership and establishes whether this is a genuine incident, what systems and which client environments are involved, and whether customer data is potentially affected. The working severity is set at this point and drives everything that follows. Because client environments are logically separate, the assessment can usually establish quickly whether the issue is confined to one engagement.

  3. Containment

    Immediate on confirmation

    The priority shifts to stopping further impact. Depending on the incident this means revoking or rotating credentials, disabling accounts, restricting an exposed entry point, taking a component out of service, or blocking a route of access. Containment decisions favour limiting harm over preserving availability, and the customer is informed when a containment action will visibly affect their service.

  4. Investigation

    Hours to days

    With the immediate risk contained, WebCastle establishes what happened: the entry point, the timeline, what was accessed or changed, and whether the issue extends beyond the environment where it was found. Available logs and cloud provider records are reviewed. Where the evidence does not support a conclusion, WebCastle says so rather than presenting an assumption as a finding.

  5. Remediation

    Prioritised by severity

    The underlying cause is fixed — a code change, a configuration correction, a dependency upgrade, a permission change or a credential replacement. Remediation covers the specific fault and any equivalent weakness found in other environments during the investigation. Changes follow the normal review and deployment process unless the severity justifies an emergency change.

  6. Recovery

    As soon as it is safe

    Service is returned to normal operation and integrity is verified. Where data was corrupted or destroyed, recovery uses cloud provider managed backups for the affected environment. Systems are watched more closely than usual for a period after restoration to confirm the issue does not recur, and the incident is not closed until that period passes without further signal.

  7. Communication

    Ongoing throughout

    Affected customers are told when their data or service is involved. WebCastle communicates what is known, what is not yet known, what is being done and what the customer may need to do, and then follows up as the picture develops rather than waiting for a complete account. Where a customer acting as controller has its own regulatory obligations, WebCastle provides the information needed to meet them. Notification content, recipients and timing for a specific customer are governed by that customer agreement.

  8. Post-incident review

    After closure

    The incident is reviewed with the people involved: what happened, what was done, what worked and what needs to change. The output is a set of owned actions — technical fixes, process changes or detection improvements — tracked to completion in the engineering backlog. Reviews are blameless and focus on the conditions that allowed the incident, not on individuals.

Incident response controls

The current maturity of each capability behind the process above.

Security reporting channel

Established

A monitored security mailbox and a published disclosure page give customers, researchers and staff a single route for reporting a suspected incident.

  • Reports reach the WebCastle security contact directly rather than a general support queue.
  • Acknowledgement of a report is a good-faith target, not a contractual commitment.

Containment through access revocation

Established

WebCastle can revoke access, rotate credentials, disable accounts and restrict entry points across the cloud consoles and administrative services it operates.

  • Multi-factor authentication on cloud provider consoles limits the value of a stolen password during an incident.
  • Because client environments are logically separate, containment in one environment does not depend on action in another.

Restoration from managed backups

Established

Recovery from data corruption or destructive change uses cloud provider native backup capabilities for managed databases and storage.

  • Restore scope and sequence are decided per environment during the incident, informed by the architecture of that engagement.

Incident response plan

Operating

WebCastle follows a consistent response approach in practice. Writing that approach into an approved plan with defined roles, thresholds and templates is under way.

  • The draft covers identification, classification, containment, investigation, remediation, recovery, communication and review.
  • Until the plan is approved, this page is the accurate public description of how WebCastle responds.

Severity classification

Operating

Severity is assessed on data sensitivity, number of affected parties and service impact. Formal written thresholds that produce the same rating regardless of who triages are being defined.

Defined response roles

In practice

A technical lead owns each live incident and coordinates the response. Named standing roles, deputies and a written escalation path are being established.

  • Leadership is involved whenever customer data may be affected.
  • Escalation contact details are held internally and are not published.

Detection sources

In practice

Incidents are identified from cloud provider native alerts, error and availability signals, customer reports, and observations by the engineering team during routine work.

  • WebCastle does not operate a security operations centre and does not provide continuous security monitoring.
  • Broadening and standardising detection coverage across environments is an active workstream.

Centralised logging

Operating

Cloud provider native logging is available in the environments WebCastle operates. Consistent enablement, retention and a single place to review logs across engagements are being worked on.

Incident record keeping

In practice

Incidents are tracked through the engineering ticketing system with the actions taken. A dedicated incident register with a standard record for each event is being introduced.

Customer notification process

Operating

WebCastle notifies affected customers when their data or service is involved. A standard notification template, an approval step and a maintained contact list are being put in place.

  • Notification terms that apply to a specific customer are governed by that customer agreement, not by this page.

Regulatory notification readiness

Under Evaluation

WebCastle is working with legal advisors to map which notification obligations apply to its engagements and jurisdictions, and how a customer as controller is supported in meeting theirs.

  • No breach-notification service level is published or offered outside a signed customer agreement.

Response exercises and forensic readiness

Planned

Tabletop exercises and a defined approach to evidence preservation are on the roadmap once the response plan is approved. Neither is in place today.

What to expect if your engagement is affected

Who contacts you
The technical lead for your engagement or a member of WebCastle leadership, using the security or account contact held for you. Contact is direct rather than through a general announcement.
What the first message contains
What has been observed, which of your systems or data may be involved, the containment action already taken, and what WebCastle needs from you. It will distinguish clearly between confirmed facts and open questions.
How updates continue
Further updates as the investigation develops, and a closing summary once the incident is resolved. Frequency is agreed with you at the start rather than fixed in advance.
Regulatory notification
Where you are the controller for the affected personal data, the statutory notification is yours to make. WebCastle supplies the factual detail you need and cooperates with your timeline. WebCastle does not publish a breach-notification service level outside a signed agreement.
Where obligations are defined
The binding notification terms for your engagement live in your customer agreement or data processing terms. Nothing on this page varies or replaces them.

Reporting a suspected incident

If you believe a WebCastle-operated system has been compromised, report it before you are certain. An early report that turns out to be nothing is far cheaper than a late one that does not.

  • Use the security mailbox

    Send the report to the WebCastle security address listed on the contact page. It reaches the security contact directly rather than a general support queue.

  • Include what you observed

    The affected system or URL, what you saw, when you saw it, and how it can be reproduced or verified. Screenshots and log extracts help.

  • Do not include live credentials or personal data

    Describe the exposure rather than sending the exposed material. If evidence must be shared, say so first and WebCastle will agree a secure channel.

  • Say if the issue is being exploited

    Active exploitation changes the priority immediately. Flag it in the subject line so it is not queued behind routine correspondence.

  • Expect an acknowledgement

    WebCastle aims to acknowledge reports promptly and to keep the reporter informed through triage. These are good-faith targets rather than contractual response times.

Related