Home/Platform/Platform architecture
Platform
Platform architecture
Four layers. The five pillars are what you work in; the three underneath are why the work does not have to be repeated, retyped or rebuilt when a regulator, a framework or a market changes.
- LAYER 01
- The five pillars — the working surface
- LAYER 02
- FalconryX — assistive intelligence across all five
- LAYER 03
- Global Libraries — the content estate you inherit
- LAYER 04
- Integration — connectors into the systems you already run
THE STACK, END TO END
One diagram, four layers, and the estate underneath.
Read it downward. The pillars are where your team works; everything below exists so that work is not repeated, retyped or rebuilt when a regulator, a framework or a market changes.
WHY THE ARCHITECTURE MATTERS
The platform is more than five modules.
The value is in the layers underneath: a common data model, governed intelligence, maintained regulatory libraries and integrations that keep evidence close to the systems that produce it.
For a CISO, that means a board question can be traced to a risk estimate and then to the control owner. For a DPO, it means a privacy obligation can be connected to the processing activity, processor and evidence. For an IT Head, it means a service dependency can be connected to the change, supplier and recovery action that affect it.
See the platform in practice
Illustrative platform viewWhy four layers
Most tools sell you the top layer and leave you to build the other three.
A platform with no library is a spreadsheet with workflow: you supply every framework, every control, every scenario, and the programme stalls for two quarters while someone types. A platform with no integration layer is a data-entry obligation, and it decays because nobody keeps typing.
The layers are also what make seven markets and six sectors tractable. A new jurisdiction is a library addition mapped to controls you already operate. It is not a second implementation.
LAYER 01
The five pillars
The working surface — where controls are owned, risk is quantified, evidence is collected, resilience is tested and assurance is reported. Named the same way across the Falconry platform family, so an organisation running corporate GRC and cyber trust sees one architecture, not two.
- Govern
- Own the cyber, privacy and technology risk mandate — and prove who decided what.
- Anticipate
- See the exposure before it lands, and size it in dollars rather than colours.
- Comply
- Meet every regulator you answer to, from one control set and one evidence base.
- Withstand
- Keep the services your customers depend on running through disruption.
- Assure
- Show the board, the regulator and your customers that the controls work.
LAYER 02
FalconryX
The intelligence layer running across all five pillars. Assistive by design: nothing it produces takes effect or leaves the platform without a named human approving it.
Where it helps
- Control mapping. Proposes mappings when a framework or regulatory pack is loaded, and flags where wording divergence means one test will not satisfy two regulators.
- Regulatory change impact. Reads a change and drafts the impact assessment against your control set, naming affected controls, policies and owners.
- Scenario calibration. Suggests FAIR parameters from incident history and asset criticality, and challenges estimates that sit outside the supporting evidence.
- Evidence review. Checks submitted evidence against what the control actually requires and returns what is missing.
- Narrative drafting. First drafts of board papers, post-incident reviews and regulator responses, every figure traceable to its source record.
- Questionnaire response. Drafts answers to customer security due diligence from your live control and evidence base.
How it is governed
- Human approval. No control mapping, risk rating, evidence acceptance or external communication takes effect on model output alone. Approval is recorded against a named person.
- Traceability. Every generated output records its inputs, the model version and the approver, and is retained with the artefact it produced.
- Tenant boundaries. Client data is not used to train shared models. Processing location follows the residency position agreed for your tenant.
- ISO 42001 alignment. The AI management system structures we apply to client estates are the ones we apply to FalconryX, and we expect clients to hold us to them.
- Opt-out. Disabled at tenant level if you prefer. The platform functions without it; the drafting simply becomes manual.
- Stated limits. It is wrong sometimes. The workflow is built on that assumption, which is why nothing it produces is self-executing.
UNDERNEATH THE PILLARS
Four masters. Everything else is a view onto them.
This is the part that cannot be bought as a module. Because a risk, a control test, a supplier in a dependency map and a processing record all point at the same underlying objects, the platform can answer questions that cut across them.
LAYER 03
Global Libraries
The content estate that makes the platform worth more than a database. Maintained centrally by us, inherited by every tenant, then tailored to your organisation rather than built from nothing.
- Regulatory library
- The instruments themselves across seven markets — national cyber regimes, central bank and market authority requirements, privacy law, sector standards — each broken into requirements, notification clocks, classification rules and reporting formats.
- Control catalogue
- A normalised control set with pre-built mappings across frameworks and regulations. Your control library starts as a tailored instance of this rather than a blank page.
- Framework library
- International standards — the ISO 27000 family, ISO 22301, ISO 42001, NIST CSF and 800-53, CIS, COBIT, SOC 2, PCI DSS, IEC 62443 — with control text and cross-mappings.
- Risk scenario library
- Severe but plausible scenarios by sector and risk type, with the FAIR parameters, decomposition structure and calibration guidance needed to quantify them rather than merely name them.
- Policy and standard templates
- Templates aligned to the control catalogue, so an approved policy links to the controls it mandates from the first day.
- Indicator library
- Key risk and control indicator definitions with calculation logic and threshold guidance, so reporting does not start with an argument about what to measure.
- Threat and technique mapping
- MITRE ATT&CK technique mappings tied to the controls that detect or prevent them, with sector threat context for the markets we operate in.
- Supplier assessment content
- Tiered questionnaire sets, evidence requirements and contract clause libraries, aligned to the regimes governing the relationship.
- Awareness and simulation content
- Role-based awareness modules and phishing simulation templates in Arabic and English, set in regional working context.
- Sector packs
- Industry overlays adding the regulation, scenarios, indicators and control emphasis specific to a sector.
How the libraries stay current. Regulatory change is monitored across the seven markets and assessed before it enters the library. Content is versioned, so you can show which version of a requirement you assessed against and when. Updates arrive as proposed changes in your tenant rather than silently overwriting decisions you have taken. Library content flows down; your control decisions, evidence and risk data are tenant-scoped and do not flow up.
LAYER 04
Integration
Evidence should come from the system that produced it. The integration layer connects the platform to the estate you already run, so governance stops depending on people retyping what a machine already knows.
- Identity and access
- User, role, group and privileged account data from your directory and identity platform. Feeds access control evidence, joiner-mover-leaver testing, segregation of duties and the human risk population.
- Cloud platforms
- Configuration and posture data from your cloud environments, feeding cloud control evidence, asset discovery and residency position.
- Vulnerability and exposure tooling
- Findings from your scanning and testing estate, deduplicated, mapped to assets and owners, prioritised by quantified exposure rather than raw severity.
- Security monitoring
- Incident and alert data from your SIEM or managed detection provider, feeding the incident record, response workflow and post-incident review.
- Service management and ticketing
- Change, incident and problem records supporting ITGC evidence, remediation tracking and control testing.
- Endpoint and device management
- Device inventory, patch state and configuration compliance feeding the asset master and control evidence.
- HR systems
- Joiner, mover and leaver events, role and department structure — driving access reviews, awareness targeting and the champion network.
- Procurement and contracts
- Supplier records, contract dates and spend, populating the supplier master and driving assessment cycles by tier.
- Open API and webhooks
- A documented REST API and event webhooks for anything not covered above, including your data warehouse and board reporting tooling.
How integration is scoped. Every connector is a maintenance commitment, so we do not connect everything at once. A first phase typically covers identity, cloud and ticketing, because those three produce the largest share of recurring control evidence. Where a system has no usable interface, the platform captures manual evidence with owner, method and date recorded, and reports the difference — because you should know which of your evidence is machine-collected and which is asserted, before a regulator asks.