01Who this document is for
This document is written for anyone in your organization responsible for procurement decisions, supplier risk, information security, or digital operations. It describes what the Radar secure tag does, how the infrastructure behind it is built, what protections are in place, and what happens when something goes wrong.
Security questions are reasonable questions. Any supplier that cannot answer them clearly, specifically, and without ambiguity should be pressed until they can. The sections below set out exactly how Radar approaches each area. We would encourage you to ask the same questions of all other digital suppliers you work with.
02Delivery model
Radar is delivered as a Software as a Service (SaaS) application. There is no software to download, nothing installed on client devices or servers, and no connection made to a client's internal networks, systems, or digital infrastructure at any point.
Access to the service is through a standard website front end. The secure tag, once placed on a client website, communicates only with the Radar platform. It does not interact with any other system on the client's estate.
SaaS delivery removes an entire category of risk associated with locally installed software: patch management, local vulnerabilities, and endpoint exposure. The attack surface is contained within the Radar infrastructure, not distributed across client environments.
03Infrastructure
The service operates across a dedicated private cloud environment running on multiple servers distributed across multiple data centers. No single server or data center is a single point of failure for the service.
Should a disk or server failure occur, the service routes around it almost immediately. Client-facing operations continue without interruption in the vast majority of failure scenarios.
Multi-site, multi-server redundancy is a foundational principle in recognized availability frameworks including ISO 22301 (Business Continuity Management) and the NIST SP 800-34 Contingency Planning Guidance. The principle is straightforward: removing single points of failure reduces the probability that any one failure cascades into a service outage.
04Operational risk
Radar is classified as a Level IV supplier in terms of operational risk to clients. Clients have no operational dependency on the Radar platform for their own core services. The client's website runs independently of Radar at all times.
If the Agency Revenue Radar service is unavailable for any reason, the secure tag does not render. It does not return an error, does not break any page element, and does not affect any other functionality on the host website. The client's visitors are unaffected.
05Incident response
Systems will experience failures. The question is not whether something will go wrong but what the response looks like when it does. The structure below sets out exactly what happens, and when, across different levels of incident severity.
06Critical incident response
A critical incident is defined as any confirmed security breach, confirmed intrusion attempt, or serious system failure that affects service delivery or the integrity of client data. When a critical incident is triggered, a named member of the Radar team is assigned, has assessed the situation, and has either resolved it or initiated the formal recovery process within 2 hours of detection.
The client is contacted directly within that same window. They are told what has happened, what has been done, and what the expected resolution timeline is. Communication continues until the incident is closed.
It is important to be precise about what the 2-hour window covers. The automated protections described later in this document (hash verification shutdown, panel invisibility, domain segregation) take effect the moment an incident is detected. They do not wait for human instruction. The 2 hours is the window for human assessment, decision-making, and client communication. The technical response is immediate.
The separation between automated response and human response is a recognized incident management principle. NIST SP 800-61 (Computer Security Incident Handling Guide) describes this as the difference between automated containment and coordinated response. Both are necessary. Neither replaces the other.
07Response timeline
- Detection: automated protections engage immediately, no human instruction required.
- Critical incident (breach, intrusion, serious failure): named human response active within 2 hours, client contacted directly.
- Immediate term (within 8 hours): no detrimental impact to client digital operations in any scenario.
- Short term (within 7 days): full service restored, incident documented, review completed.
08Client website during any incident
Throughout any incident at any severity level, the client's website operates normally. The secure tag is the only Radar component on the client's site. If it cannot be served, it does not render. Nothing breaks. No error is presented to visitors. No page functionality is affected.
The Radar system and the client's website are structurally independent. An incident in the Radar platform has no path into the client's infrastructure.
09Data
The data Radar collects in the course of operating the service relates exclusively to publicly available web page content. Each item of data collected is already available in the public domain to any person with internet access. This data carries no personal information, no commercially sensitive business data, and no credentials or authentication material. It has no value to an attacker. There is no meaningful incentive to target it.
Under GDPR Article 32, organizations are required to implement appropriate technical measures relative to the risk presented by the data they process. Where data carries no personal or commercial sensitivity, the residual risk is minimal. Radar's data scope is deliberately narrow for this reason.
10The secure tag
The secure tag sits on the client's website and connects to the Radar platform. Three distinct layers of protection govern that connection and the content it delivers. Each addresses a different category of risk. All three operate simultaneously and continuously.
11Anti-hijacking
Anti-hijacking software was developed specifically to prevent the secure tag from being used as an entry point into a client's web estate. The scenario it addresses is precise: a vulnerability in a client's website could, under specific conditions, create a path through the secure tag into that infrastructure. The anti-hijacking software is engineered to close that path.
Each panel delivered through the secure tag has its own security seal and is monitored continuously. There is no external access to the Radar systems.
12Anti-sabotage
Anti-sabotage software addresses a separate risk: the content of a panel being altered, or the mechanism that delivers it being compromised. The specific scenario is one where an attacker has gained internal access to the system and is attempting to push their own content through a panel onto a client's website.
If that activity is detected, the system prevents the content from being displayed before it reaches any visitor. The panel defaults to invisible mode. The client's visitors see nothing from the attacker. The host website's availability and performance are unaffected.
13Hash verification
Each panel delivered through the Radar platform carries a unique 256-character cryptographic hash code. This hash is a mathematical representation of the exact content of that panel. The system holds the original hash value and checks each panel delivery against it. Verification runs in excess of 50,000 verifications per calendar day.
If a hash does not match, the panel content has been altered. The system raises an automatic alarm. Depending on severity, the panel is removed from display and a managed shutdown process begins. Content that has been tampered with does not reach the visitor.
Cryptographic hash verification is a foundational integrity control described in NIST SP 800-57 and used widely in software integrity verification, file authentication, and secure delivery systems. A mismatch between the stored hash and the delivered content is mathematically conclusive evidence of tampering. With in excess of 50,000 verifications per calendar day, the detection window is effectively zero.
14Domain segregation
The Radar service delivery infrastructure operates within its own segregated subdomains, entirely separate from the organization's front-facing web and email services. Front-facing services carry inherent exposure to denial of service attacks, flooding, and other high-volume attack vectors. These are well-documented risks for any publicly accessible service.
Segregation means that exposure cannot reach the delivery infrastructure. An attack on the front-facing services has no path to the layer that handles secure tag delivery and PDF conversion.
Network segmentation and domain segregation are core principles in enterprise security architecture. NIST SP 800-53 Control SC-7 (Boundary Protection) and the broader zero-trust architecture guidance from NIST SP 800-207 both describe segmentation as a primary control for limiting the blast radius of any attack.
15Real-world testing
The security system has been tested under real operational conditions, not in a laboratory or simulated environment. Testing was conducted across 133,700 websites, with a single scale test covering 3,560 sites simultaneously.
In those tests, the maximum time between detection of a security event and system shutdown was under 750ms. That figure represents the worst case recorded across the full test population. Throughout testing, alerts were raised and triaged by severity. System behavior was reviewed continuously. Where a simulated problem was detected, the relevant client was alerted. Where a problem was assessed as critical, site access was suspended. Each test outcome was documented.
750ms is less than one second. In the context of a web-delivered attack, sub-second detection and response is the difference between an incident being contained and an incident becoming a breach. This figure was not modeled or estimated. It was recorded under load.
16Questions to ask any supplier
The measures described in this document represent a specific and deliberate approach to securing a tag-based service. Security questions are not unreasonable. They are appropriate due diligence for any supplier relationship involving code or content on your website. The following are worth asking of any supplier in this category:
- What protection exists to prevent your tag being used as an entry point into our infrastructure?
- How is the integrity of content delivered through your tag verified, and how frequently?
- What is your defined response time for a critical security incident?
- How is your service delivery infrastructure separated from your public-facing services?
- What data do you collect, where is it stored, and what is its retention period?
- Has your security system been tested at scale, and what were the results?
If a supplier cannot answer these questions with specific, verifiable responses, that is itself a security signal.
17One thing we do not say
No service is unconditionally secure. Any supplier that tells you otherwise is telling you something that is not true. What we can account for is each protection described in this document: the architecture behind it, the testing it has been through, and the response process that begins when something goes wrong.
If you have specific security questions beyond what is covered here, or if your organization requires supporting documentation for procurement purposes, contact us directly at [email protected].