Skip to content
Art2link ESB v2.02 LTS HomeDocumentationBlogContact
Security & compliance/Compliance

Compliance

A compliance review asks three things of a middleware vendor: what does the infrastructure inherit, what evidence does the product produce, and how does the vendor itself behave? Art2link ESB’s answers lean on an unusual strength, the product runs inside your compliance boundary, not ours.

Because the platform deploys into your subscription and runs entirely on managed Azure services, the infrastructure layer arrives already covered: Microsoft’s certifications apply to App Service, SQL, Service Bus, and Storage, and workloads handling PHI sit on services covered by Microsoft’s Business Associate Agreement, with no third-party SaaS in the data path to drag into scope. Data processing happens where your policies already govern: message bodies, tracking data, and logs are stored and processed inside your tenant, in your region, under your Azure RBAC, your locks, and your access reviews.

For the questionnaire. “Where is our data processed, and under whose controls?”, inside your own Azure subscription, under yours. That answer removes most of a vendor-risk assessment’s data-handling section.

Frameworks do not ask whether you had controls; they ask you to prove they operated. That proof machinery lives in Logs and is summarized here rather than duplicated: three correlated streams, infrastructure, application, and audit, with the audit stream hash-chained and append-only, archived immutably, retained six years by default, and pre-mapped to SOC 2 CC controls and HIPAA citations. Sign-ins, role grants, denied attempts, credential rotations, and retention-policy changes all land there; the audit stream even records reads and exports of itself.

Edition gating. Infrastructure and application streams ship in every edition; the audit stream, hash-chained storage, immutable archive, and legal-hold export are Grow and Enterprise capabilities. If audit evidence is the requirement, Grow or Enterprise is the edition.

No standing access. Cerebrum City has no background connection to a deployed instance and cannot reach into a customer environment at will. Access exists only where an engagement contract establishes it, scoped to what the contract covers.

Updates are contract-gated and customer-approved. Product updates are pushed from Cerebrum City’s DevOps pipelines into an environment path the customer sets up and grants. An update lands in pre-production first; the customer tests their own integrations against it; only after a written sign-off does the same update proceed to production. The customer is the gate at every step, nothing reaches a production bus without their signature.

Certifications. Cerebrum City does not yet hold formal certifications of its own (SOC 2, ISO 27001) and does not claim otherwise. The architecture above (customer-tenant deployment, no standing access, no vendor cloud in the data path) is deliberately shaped so that a deployment’s compliance story rests on Microsoft’s certifications and the customer’s own controls rather than on the vendor’s paperwork. Formal certification work is on the company roadmap and this page will state it plainly when it lands.