ISO 27001

ISO 27001-Aligned Healthcare FHIR Backend

ISO 27001 certifies an information security management system, not a single product. The certification scope decides where the auditor looks and which controls evidence is needed. Fire Arrow is developed under an ISO 27001-aligned QMS (certification in progress) and ships release artifacts that document the backend-layer behavior an auditor cares about, so the customer can put the certification boundary where it fits the deployment.

Read the security page Book an ISO 27001 architecture review

What you can build

Annex A controls evidence aligned with the deployment
Identity, access control, logging, and change management each have a documented configuration the auditor can verify.
Hosting boundary flexibility
Evoleen-hosted deployments run on ISO 27001-certified cloud infrastructure under Evoleen's ISO 27001-aligned QMS (certification in progress). Self-hosted deployments fit inside the customer's certification scope.
Documented controls inheritance
The customer's ISMS documents which controls are inherited from the deployment configuration and the supplier relationship, and which are operated by the customer's own organization.

What you get out of the box

Capability With Fire Arrow Building it yourself

Access control (A.5.15-A.5.18, A.8.2-A.8.5) Deny-by-default rules tied to identity. Audit per access. Privileged access through service accounts with rotation. Custom controls evidence per service.

Logging and monitoring (A.8.15-A.8.16) Identity-attributable audit log shipped to the operator's log infrastructure. Retention controlled by the operator. Custom logging across service boundaries, with completeness left to be proven.

Cryptography (A.8.24) TLS for client traffic. Encryption at rest at the database layer the operator manages. Custom key management across services.

Operational security (A.8.32) Versioned releases, reproducible builds, documented change history. In-house change-management discipline applied across the stack.

Supplier relationships (A.5.19-A.5.22) Evoleen Technology supplies the backend under documented terms. Subcontractor relationships disclosed. Supplier evaluation per third-party library.

Information security incident management (A.5.24-A.5.30) Security advisory channel for production customers. Each advisory describes affected versions, impact, and recommended remediation timeline. Custom advisory channels per supplier.

Who this is for

Healthcare product teams pursuing or maintaining ISO 27001 certification, and security architects deciding where the certification boundary should sit relative to the FHIR backend.

Clinical applicability

A healthcare SaaS holds an ISO 27001 certification covering its development organization. The backend operates inside a hosted environment that needs to be inside the certification scope or covered by a flow-down to the hosting provider's certification.

Where the certification boundary actually goes

ISO 27001 certifies an ISMS scope. For a healthcare SaaS the scope often covers the development organization, the production environment, and the customer-facing service surface. The FHIR backend can sit inside that scope (when the customer hosts it) or outside it (when a third party hosts it and the third party's certification is referenced).

Both shapes are valid. The wrong shape is one where the boundary is unclear, because the auditor cannot verify controls they cannot see and the customer cannot inherit controls they have not documented as inherited.

Evidence the backend layer produces

Annex A controls relevant to the backend layer have documented configuration the customer's auditor can review directly. Access-control evidence is the rule set, the identity-mapping configuration, and the audit-log shape. Logging-and-monitoring evidence is the audit retention configuration and the integration with the operator's log infrastructure. Operational-security evidence is the published release notes and change history per version.

These artifacts are part of the deployment the customer operates. Fire Arrow's product documentation describes how each one works and where it sits in the configuration. The customer's ISMS documents which controls are inherited from the deployment configuration and the supplier relationship, and which are operated by the customer.

Hosted vs self-hosted boundaries

Evoleen-hosted deployments operate inside Evoleen Technology's environment. The operating environment runs on ISO 27001-certified cloud infrastructure under Evoleen's ISO 27001-aligned QMS (certification in progress). Once Evoleen's certification is in place, the customer's ISMS can reference Evoleen's certification as a supplier control, and the customer's auditor can request a supplier-procedure audit of Evoleen as a separate engagement. Internal QMS documents are not opened up as a customer deliverable in either case.

Self-hosted deployments operate inside the customer's environment. The customer's ISMS extends to cover the operating environment, with Fire Arrow's release artifacts and product documentation covering the backend behavior the auditor evaluates. The split is documented as part of the controls inheritance description.

Related docs

FAQ

Is Fire Arrow ISO 27001 certified?

Evoleen Technology operates under an ISO 27001-aligned ISMS, with certification in progress. For Evoleen-hosted deployments the operating environment is in scope of Evoleen's ISMS. For self-hosted deployments the operating environment is the customer's responsibility and the customer's ISMS scope decides the certification boundary.

Can I inherit Evoleen's certification for my own audit?

Once Evoleen's ISO 27001 certification is in place, the customer's ISMS can reference it as a supplier control when Evoleen hosts the deployment. The customer's auditor can also request a supplier-procedure audit of Evoleen as a separate engagement. The customer's ISMS still has to document which controls are inherited and which are operated by the customer.

What evidence do I get from Evoleen?

Per release: container images with pinned dependencies, release notes, change history, intended use of the backend, known anomalies and limitations, and security advisories. Per the product itself: the deployment configuration the customer operates (rules, identity mappings, audit retention) and the product documentation that describes how each piece works. Internal QMS documents are not a customer deliverable. After Evoleen's ISO 27001 certification is in place, the certificate and a supplier-procedure audit (where the customer's auditor requires one) become available.

How do upgrades and patches work under the ISMS?

Each release ships with documented changes and a security-advisory entry where applicable. The customer's change-management procedure decides when to apply updates; security advisories carry recommended timelines.

What about HITRUST or SOC 2?

HITRUST and SOC 2 evidence overlap heavily with ISO 27001 evidence in the backend layer. The release artifacts and deployment configuration the customer references are the same; the difference is which controls framework the customer's auditor maps them into.