Platform
AIDE Chain, Blueprint, shared identity/tenancy/entitlement services, PostgreSQL persistence, Blob artefacts, telemetry connectors and operational monitoring.
Current assurance status
AIDE Chain is not currently claiming certification to ISO/IEC 27001:2022 and is not currently claiming a SOC 2 Type II report. This page describes implemented technical controls, the proposed assurance scope, the evidence already produced by the platform and the remaining work required before independent certification or attestation.
1. Proposed assurance scope
The proposed organisational scope is the development, operation and support of the AIDE managed SaaS platform, including AIDE Chain and AIDE Blueprint, the shared control plane, Azure-hosted production services, GitHub-based software delivery, customer-support processes and the business processes used to administer access, suppliers, incidents, continuity and change.
Cloud and delivery
Azure App Service, Azure Database for PostgreSQL, Azure Blob Storage, Azure Monitor/Application Insights, deployment configuration and GitHub CI/CD.
People and process
Access administration, secure development, support, incident response, supplier management, risk management, continuity, internal review and management oversight.
External dependencies
Material service providers and subprocessors used to operate AIDE, including cloud, source-control/deployment and relevant commercial or communications services, are to be recorded and governed through the supplier-management process.
The final ISO certification scope and SOC 2 system boundary must be confirmed with the chosen certification body/service auditor before the external examination begins.
2. ISO/IEC 27001:2022 readiness
ISO/IEC 27001:2022 specifies requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS). AIDE's preparation model is therefore broader than software security alone: it must show that information-security risks are identified, treated, operated, monitored, reviewed and improved as part of the business.
Context, scope and governance
Define the ISMS scope, interested parties, information-security objectives, responsibilities, policy framework and management accountability.
Risk assessment and treatment
Maintain a repeatable information-security risk methodology, risk register, treatment decisions, control owners and residual-risk acceptance. The Statement of Applicability records which controls are necessary and why.
Operational control
Operate access, change, secure development, logging, backup, supplier, incident, continuity and other risk treatments at the frequencies defined by the ISMS, retaining evidence that the controls actually occurred.
Performance evaluation
Measure objectives, monitor the ISMS, perform internal audits and conduct management reviews using retained evidence, findings, metrics and risks.
Continual improvement
Record nonconformities, corrective actions, lessons from incidents and audit findings, and verify that remediation is effective.
Current standard baseline
Certification preparation should reference ISO/IEC 27001:2022 and take account of the applicable 2024 climate-action amendment when the ISMS context is reviewed.
AIDE's Annex A preparation will use the risk assessment to determine necessary controls rather than treating the control catalogue as a checklist. Control implementation and evidence will be maintained in a Statement of Applicability and supporting control register.
3. SOC 2 Type II readiness
A SOC 2 examination evaluates controls relevant to the Trust Services Criteria for security, availability, processing integrity, confidentiality and privacy. For AIDE's initial preparation, the strongest commercial fit is expected to be Security, Availability and Confidentiality, subject to confirmation with the appointed service auditor and customer requirements.
System description
Document the services provided, infrastructure, software, people, procedures and data; define system boundaries, material dependencies, subservice organisations and customer responsibilities.
Control design
Map risks and service commitments to control activities covering areas such as access, change, operations, monitoring, incident response, availability and confidentiality.
Operating evidence
Retain evidence at the stated control frequency: access reviews, changes, security scans, backup/recovery tests, incident records, supplier reviews, monitoring evidence and other recurring activities.
Type II observation period
The service auditor examines both control design and operating effectiveness across a defined period. The observation period and testing approach are agreed with the auditor before the examination.
Management responsibilities
Management prepares the system description and assertion and is responsible for operating the controls. The independent CPA/service auditor evaluates the description, control design and operating effectiveness.
Report handling
A SOC 2 Type II report is an assurance report rather than an ISO-style certificate and is normally shared under controlled distribution with customers and other authorised parties.
4. Technical evidence already generated by AIDE
The current platform already creates a substantial technical evidence base that can feed the ISMS and SOC 2 control register.
Identity and access
Application-native authentication, TOTP MFA, recovery codes, secure session handling, authentication stamps, account lockout, role/capability checks, project grants and server-side tenant ownership checks.
Tenant isolation
Explicit organisation scope throughout application services, generic not-found responses for unauthorised tenant resources, private artefact resolution and PostgreSQL row-level-security policies with cross-tenant regression tests.
Secure development
Pull-request review workflow, automated application/PostgreSQL tests, dependency auditing, static analysis, reviewed-exception drift checking and repository-history secret scanning.
Software supply chain
Pinned runtime dependencies, reproducible CycloneDX SBOM generation, immutable release artefacts, SHA-256 integrity evidence and exact-release promotion/health verification.
Integration security
Outbound-first architecture, constrained credential namespaces, HTTPS/destination validation, redirect rejection, bounded responses, sanitised upstream errors, explicit tenant context and fail-closed automated telemetry.
Monitoring and recovery
Correlation IDs, structured logs, Application Insights, liveness/readiness checks, PostgreSQL point-in-time recovery, Blob version/soft-delete protection and documented recovery drills.
Public attack-surface controls
CSRF protection, bounded request payloads, public authentication/integration rate limits, secure cookies, HSTS on secure deployments, security headers, restrictive browser permissions and Content Security Policy controls.
Auditability
Significant control operations, interventions, automated-checkpoint provenance, telemetry quality/conflict state and architecture discovery evidence are retained for investigation and review.
5. Remaining readiness work
The principal gap is no longer the existence of basic application controls; it is formalising the organisational management system and accumulating recurring evidence that an external auditor can test.
ISMS and policy set
Approve an information-security policy, ISMS scope, risk methodology, control register, Statement of Applicability and supporting policies/procedures for access, change, incident, suppliers, continuity and secure development.
Governance cadence
Establish named control owners, review frequencies, information-security objectives, risk review, internal audit, management review and corrective-action tracking.
People controls
Formalise joiner/mover/leaver activities, confidentiality expectations, security responsibilities, security awareness and periodic access review evidence.
Supplier governance
Maintain the material supplier/subprocessor register, due-diligence evidence, contractual/security requirements and periodic supplier review.
Incident and continuity exercises
Retain incident records and conduct documented incident-response and business-continuity/recovery exercises, including lessons and follow-up actions.
External assurance
Complete a formal gap assessment, internal audit and management review for ISO preparation; appoint an accredited certification body. For SOC 2, engage a qualified service auditor, agree the criteria/system description and accumulate evidence across the defined Type II period.
6. Defence-in-depth items still planned
Several technical uplifts remain on the roadmap. They are intentionally shown here so customers and assessors can distinguish implemented controls from planned improvements.
Secrets
Migrate remaining application secrets from direct App Service settings to Azure Key Vault references backed by managed identity; use a Key Vault-protected key for recoverable MFA TOTP seed encryption.
Database boundary
Move the live application to a non-owner, least-privilege PostgreSQL runtime identity so installed row-level-security policies become an independent production tenant boundary; private PostgreSQL networking remains a planned deployment uplift.
Deployment identity
Replace long-lived Azure publish-profile credentials with GitHub-to-Azure OIDC/federated deployment authentication.
Browser policy
Promote the stricter report-only Content Security Policy to enforced mode after staging/compatibility evidence has been reviewed.
Edge and egress controls
Where required, place intentionally enabled inbound integrations behind approved WAF/source-network/mTLS controls and reinforce sensitive outbound connector allow-listing at the Azure network layer.
Independent testing
Commission external penetration testing and track findings through the same risk, remediation and evidence process used by the ISMS.
7. Assurance evidence register
The evidence register is intended to give each control an owner, frequency, evidence source and retention expectation. Typical evidence includes:
Access
User/role listings, MFA state, privileged-access review, joiner/mover/leaver records and access-removal evidence.
Change and SDLC
Pull requests, test results, security scan results, SBOMs, release checksums, change approvals, deployment identity and rollback/recovery records.
Operations
Monitoring alerts, incident tickets, service-health evidence, backup configuration, restore drill results, vulnerability findings and remediation records.
Governance
Risk register, treatment plans, Statement of Applicability, objectives/metrics, internal-audit results, management-review minutes and corrective actions.
Suppliers
Supplier inventory, due diligence, contracts, security/availability commitments and review decisions.
Customer assurance
Architecture/data-flow material, security overview, shared-responsibility statements, customer-specific control deviations and approved assurance responses.
8. Shared responsibility
AIDE secures the managed SaaS platform and the controls inside its defined service boundary. Customers remain responsible for the security and correctness of their own source systems, user devices, identity administration outside AIDE, connector permissions/credentials they provide, customer-specific data classification, and the governance decisions made using AIDE's outputs. Customer-specific controls can be documented as complementary user-entity responsibilities where relevant to the SOC 2 system description.
9. External audit path
ISO/IEC 27001
Complete scope and ISMS design → operate controls and retain evidence → conduct internal audit → conduct management review → close corrective actions → engage an accredited certification body for Stage 1 and Stage 2 certification audit.
SOC 2 Type II
Agree system boundary and Trust Services Criteria with the service auditor → finalise control matrix and system description → operate controls across the defined observation period → provide evidence samples/explanations → receive the independent Type II assurance report.
10. Authoritative references
For the standards themselves, refer to the official sources: ISO/IEC 27001:2022 — Information security management systems — Requirements, ISO/IEC 27001:2022/Amd 1:2024, and the AICPA & CIMA SOC 2 / Trust Services Criteria resources. This public page is a readiness summary and does not replace the licensed standard, professional advice or the requirements of the appointed auditor/certification body.
Procurement use
Prospective customers can use this page together with the Solution Architecture and Security & Assurance pages to identify the evidence needed for due diligence. Sensitive environment evidence is provided through a controlled customer-assurance process rather than published openly.