Assurance: the comfort of knowing what your risks are, how you mitigate them, and the evidence your controls
are working.
Most cloud security claims start with governance and hope nobody asks what's underneath. We start evidencing at the hardware and build upward.
There is a material difference between a provider that gives a contract promise to protect your data and a platform architecturally designed to reduce channels for data exposure risks.
Assurance in the hardware.
Most organisations evaluating a cloud platform will never know what runs inside the hardware it depends on.
The global technology supply chain is sufficiently complex that most manufacturers cannot fully account for their own component provenance - a risk serious enough to be declared a national emergency in the United States in 2019.
Autonomy Cloud is built on hardware 100% designed, manufactured, and assembled in the UK or United States with full supply chain transparency and component-level auditability.
Every element of the stack can be accounted for:
The software is compiled entirely from source by our vendor engineers - either as open source or written in-house. Nothing opaque sits between the hardware and the platform you operate.
The software stack was developed against NIST SP 800-53 FISMA High controls from the outset - not retrofitted after the fact. Security was a design constraint that had to be fulfilled, not considered as an afterthought.
The architecture is stateless by default, supporting recovery to a known-good state and certified immutable backups that is provably resistant to ransomware and malicious modification.
This is backed by deployment architectures that identify and harden the platform from ingress of encrypting malware.
Post-quantum cryptographic readiness is incorporated into the platform design, addressing threat vectors that most current infrastructure is not yet built to resist.
What's wrong with risk-based assurance models today.
For decades, security decisions were governed by a clear constraint:
cheap, fast, or secure: choose any two, but security was non-negotiable.
That discipline produced rigorous frameworks, formal risk assessment, and genuine accountability for the protection of data and systems.
Policy priorities shifted.
The observation that a sufficiently motivated attacker will eventually breach a determined target became a justification for treating accepted risk as a default posture rather than a carefully considered risk assessment last resort.
We understand the pragmatism.
But think it's sometimes applied too broadly, and too early in the process.
Identifying a credible threat and accepting residual risk after mitigation is a legitimate and sometimes necessary position. Accepting risk as a substitute for assessing it is not.
The practical difference between the two is often invisible in a compliance document - and our experience tells us that's a serious problem.
Why GRC no longer delivers what it should.
Governance, Risk and Compliance was designed to give organisations a structured means of managing their information security obligations. We have observed it, across a significant number of cases, evolving into something rather different.
Governance has become, for too many organisations, principally a documentation exercise.
Formal risk assessments - based on asset valuation and threat intelligence; evaluating the real-world impact of a breach of confidentiality, integrity, or availability - is rarely conducted with the rigour the GRC frameworks expect. Compliance activity can then shift from demonstrating that obligations are met, to managing the exposure of being found "non-compliant".
None of this reflects on the people doing the work. It can be simply explained by the adage:
Tell me how you will measure me, and I will act accordingly.
The objective of most GRC activities is to demonstrate a level of achievement against one or more standards; and as a result most GRC structures - point-in-time audits, scope-limited certifications, badge-driven procurement - are constructed to produce the outcome expected.
This does not mean GRC is a pointless activity; simply that it is an area where repeated re-assessment by rote is common.
For too many organisations the GRC process has become more important than the insights it is supposed to reveal.
The question that matters
Have you defined your security target?
Can you show how you did so? Have you achieved it?
Can you demonstrate the achievement?
In our experience, the first question is the one most frequently missing from a GRC activity.
What we commonly observe instead
A compliance posture that is difficult to maintain, but presented with absolute confidence - in the process and the outputs
Scope exercises that are designed to reduce controls and cost rather than reflect operating reality
"Cloud shared responsibility model" certifications that covers the provider's management system; but not the customer's risks.
Generic framework controls applied without contextualisation to the organisation's specific legal or regulatory obligations.
Certification that's achieved
without real contextualisation.
Standards-based certification provides a useful generic baseline. Nothing more.
ISO 27001, CSA CCM, NIST SP800-53, PCI DSS - these are serious frameworks built by serious, skilled and experienced people.
The problem is not with the standards themselves. It is how they are applied and audited.
Scoping exercises - which should identify and define what is to be diligently covered, and the evidence needed - can sometimes be used to minimise the number of controls to be evidenced.
The result is a certificate that covers considerably less than it appears to; and far less than an organisation may actually need. This gives a false degree of comfort to those who rely on it while not fully disclosing what falls outside its boundaries.
If properly scopd the controls applicable to a financial services organisation ought to be different to a law enforcement agency, and to a commercial Cloud SaaS provider.
The control families may be commonly grouped, but the nature, type, and sources of control evidence should be entirely different and specific to the customer. Applying the same framework to all three without contextualisation produces the appearance of assurance rather than its substance.
ASK YOURSELF THIS:
How can a hyperscale public cloud provider hold a single ISO 27001 certification covering a globally diverse customer base, operating across hundreds of legislative regimes, operating hundreds of business types, and processing widely different categories of data?
The answer is that its scope covers the provider's own management system only - not the customer's deployed services and risk position. That distinction is not always clearly communicated, and is rarely understood.
This is the reality of the modern Shared Responsibility Model : the hyperscaler is responsible only for their own management risks, which they boundary in contract terms; you carry the responsibility for everything else.
Genuine assurance requires contextualisation across the full stack
Service type and deployment model
Data classification and the realistic impact of its compromise
Sector-specific regulatory obligations
The complete jurisdictional picture - including legislation that may apply extraterritorially without the data owner's awareness
Security and Assurance by Default:
Contextualised by sector, sovereignty, and regulatory obligations.
We started with a question:
What does a platform need to look like so that operating it securely is the path of least resistance?
Experience tells us that only when it takes more effort to run the system insecurely than securely are you able to achieve Security by Default.
The answer can be found in applied architectural patterns:
Selecting patterns from a catalogue that are aligned to your risk tolerance, security objectives, regulatory obligations or legal constraints then gives you an infrastructure blueprint aligned to your specific operating context.
Once defined, applying the patterns and controls rigorously - and flagging deviations from them - delivers the target: a known and assured state.
These patterns are not theoretical or paper exercises. They're proven real world approaches that emerged from 20 years of operational deployments across national security, policing, criminal justice, financial services, and regulated infrastructure programmes.
They exist because we found the gaps in practice, and addressed them.
When an organisation deploys on Autonomy Cloud using our published blueprints, they are starting from a baseline designed to be correct - with the assurance framework built into the architecture rather than applied after deployment.
Working on a platform that's harder to operate insecurely than its default secure by design state.
A platform that is genuinely Secure by Default and Contextually Assured to your business.
This governance framework was first developed for the UK Government CTO office in 2006-7.
It informed the network of networks strategy till 2020 and the original Community of Interest architecture for UK national policing connectivity to wider justice partner infrastructure.
It has been continuously developed through operational deployments in national security, criminal justice, defence-adjacent, and regulated sector programmes.
It predates the thinking of every other commercial sovereign cloud product on the market.
Evidence controls once.
Apply it everywhere.
We've been working on the multi-framework compliance mapping problem since 2010; when we built the first multi-matrix security control spreadsheets for cloud shared responsibilities for the UK Pan-Government Accreditor.
The CSA CAIQ identified the same structural problem (and took broadly the same parallel approach).
Its a very valuable generic toolset, but geared at Cloud Service Providers (CSP's) meeting GRC tick-box control objectives.
It doesn't address the tenant or service contextualisation that most organisations need, and was never designed to do so.
This leaves a big gap : Cloud providers fill it with contract clauses, but do they protect the customer or the CSP?
The Assurance Rosetta is our evolved answer to that gap.
Evidence your controls once: the Rosetta translates that evidence across every framework your organisation needs to satisfy - simultaneously, and without rework.
ISO 27001, NIST SP800-53, CSA CCM, PCI DSS; plus sector-specific standards, applicable national and supra-national legislation and regulations - all mapped, cross-referenced, and kept current by us, ready for you to use.
The Rosetta's most fundamental function is capturing the specification of your operating context.
A few questions allow it to produce a meaningful output: the more you explain, the better the contextualisation.
Without context, control framework outputs are a generic answer to someone else's question.
With it, the output reflects your actual obligations, and those of your servivce providers, partners and supply chain.
We embed contextualisation as a core assurance requirement, not a post event lessons learned measure.
Contextualisation inputs
Service type & deployment model
Data classification & impact of compromise
Sector & regulatory regime
Full jurisdictional stack
Regulatory Intelligence
The regulatory and legislative landscape changes continuously.
A point-in-time certification reflects only what was true on the date of your last audit.
We maintain the Rosetta's control mappings and regulatory content on a continuous basis - incorporating legislative changes, regulatory updates, and relevant case law for every regime in which you operate as they occur.
This is a core part of our Sovereign Cloud capability: a living compliance framework tailored to your business area, data type, regulatory frameworks and nationally applicable legislation.
We believe Rosetta is a globally unique but vital proposition.
Available as a managed compliance intelligence feed: this is a threat intelligence model applied to your regulatory exposure rather than your attack surface.
More than three decades of applied assurance experience.
Our architecture and security practice is grounded in the original technical specifications and policy frameworks that underpinned UK government information security and national infrastructure - work that predates most current compliance tooling by a decade or more.
We have watched the foundations we helped to build get layered over, simplified, sometimes misapplied, and occasionally forgotten entirely.
That's why we built Autonomy the way we did.
Accreditations
CESG CCP Lead IA Architect (BCS) | CLAS | Lead Information Risk Advisor CCP | ITPC | IISP | TOGAF
Experienced in deployment and operations at US/UK/NATO SECRET classification.
Sectors
ARC@NE
The Assurance Rosetta Compliance Assessment Neural Engine
Whereas the Rosetta provides the framework and the intelligence, ARC@NE applies both to your actual running platform - in near real time, and continuously.
ARC@NE is a dedicated small language model trained on the Rosetta's control mappings, relevant contextualised standards, and regulatory intelligence content.
Designed to be deployed within a customer tenancy from the Autonomy secure marketplace - it runs inside your Domain of Control, with no data leaving your environment.
Working in tandem with your Security Event Monitoring - ARC@NE continually assesses live platform configuration and deployment against your contextualised control set.
It identifies gaps, prioritises remediation actions, and produces plain-language compliance reporting meaningful to both technical teams and governance stakeholders.
No more point-in-time audit, followed by remediation cycle.
A running picture of where you stand, and a source of advice on what you ought to address first.
Assurance starts with a conversation about your obligations.
Regulatory requirements, jurisdictional exposures, risk tolerance -
key constraints to be understood before anything is deployed.
We'll work through these with you first, then take things from there.