Who this document is for
This document is written for anyone in your organisation responsible for procurement decisions, supplier risk, information security, or digital operations. It describes what the aicm 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 aicm approaches each area. We would encourage you to ask the same questions of every digital supplier you work with.
Service architecture
Delivery model
aicm 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 aicm 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 aicm infrastructure, not distributed across client environments.
Infrastructure
The service operates across a dedicated private cloud environment running on multiple servers distributed across multiple data centres. No single server or data centre 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 recognised 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.
Operational risk classification
aicm is classified as a Level IV supplier in terms of operational risk to clients. Clients have no operational dependency on the aicm platform for their own core services. The client's website runs independently of aicm at all times. If the aicm 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.
Incident response and recovery
Every system 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.
Critical incident: 2-hour 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 aicm 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) activate 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 recognised 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.
Response 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
Client website during any incident
Throughout any incident at any severity level, the client's website operates normally. The secure tag is the only aicm 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 aicm system and the client's website are structurally independent. An incident in the aicm platform has no path into the client's infrastructure.
Data
The data aicm collects in the course of operating the service relates exclusively to publicly available web page content. Every 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, organisations 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. aicm's data scope is deliberately narrow for this reason.
The secure tag: how it is protected
The secure tag sits on the client's website and connects to the aicm 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.
Anti-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 aicm systems.
Anti-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.
Hash verification
Every panel delivered through the aicm 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 every 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 pipelines. 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.
Domain segregation
The aicm service delivery infrastructure operates within its own segregated subdomains, entirely separate from the organisation'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. The principle is that a breach in one segment should not provide access to another.
Real-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 deployment 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 behaviour 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. Every 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 modelled or estimated. It was recorded under load.
Questions 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.
One 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 every protection described in this document: the architecture behind it, the testing it has been through, and the response process that activates when something goes wrong.
If you have specific security questions beyond what is covered here, or if your organisation requires supporting documentation for procurement purposes, contact us directly.