Skip to main content

Security & Compliance

STOA Platform is designed with European enterprise security requirements at its core. This page explains how STOA helps organizations meet regulatory obligations while maintaining operational efficiency.

Regulatory Compliance​

DORA (Digital Operational Resilience Act)​

The Digital Operational Resilience Act requires financial entities to strengthen their ICT risk management. STOA addresses key DORA requirements:

DORA RequirementHow STOA Helps
ICT Risk ManagementCentralized Control Plane with full audit trail of all API operations
Incident ReportingReal-time alerting via Grafana + structured logs in OpenSearch for incident reconstruction
Operational Resilience TestingBuilt-in health checks and circuit breakers
Third-Party RiskAPI subscription governance with approval workflows and usage monitoring

DORA Compliance Flow:

Compliance Disclaimer

STOA provides tools and features to support your compliance efforts. Certification, audit, and ultimate compliance responsibility remains with the implementing organization. Consult qualified advisors for your specific regulatory requirements.

NIS2 (Network and Information Security Directive)​

NIS2 expands cybersecurity requirements across essential sectors. STOA supports compliance through:

  • Supply Chain Security — Full provenance tracking of API dependencies and third-party integrations
  • Sovereignty — European-hosted Control Plane option with data residency controls
  • Incident Handling — Automated alerting and audit logs meeting 24-hour reporting requirements
  • Access Control — Role-based access with Keycloak integration and multi-tenant isolation
Compliance Disclaimer

STOA provides tools and features to support your NIS2 compliance efforts. Certification and audit responsibility remains with the implementing organization.

RGPD (General Data Protection Regulation)​

STOA implements privacy-by-design principles:

CapabilityImplementation
Data MinimizationConfigurable log anonymization — mask PII in request/response logs
Data ResidencyControl Plane Cloud EU or Full On-Premise deployment options
Right to AccessAPI usage logs per consumer with export capabilities
Data PortabilityStandard OpenAPI contracts, no vendor lock-in
Compliance Disclaimer

STOA provides privacy-by-design features to support GDPR compliance. Data protection responsibility remains with the data controller.

Data Residency Architecture​

Understanding what data flows where is critical for compliance. STOA's hybrid architecture provides clear boundaries:

What Stays On-Premise​

  • Business Data — All API request/response payloads containing business information
  • User Identities — Oracle OAM/OIM remains the master identity provider
  • Credentials — Secrets, certificates, and sensitive configuration
  • Raw Logs — Detailed transaction logs (only aggregated metrics sent to cloud)

What Goes to Cloud​

  • API Metadata — Catalogue information, OpenAPI specifications
  • Aggregated Metrics — Request counts, latency percentiles, error rates
  • Subscription Data — Who has access to which APIs
  • Federated Tokens — Short-lived tokens via Keycloak federation (not credentials)

Security Architecture​

Authentication & Authorization​

  • OIDC Federation — Keycloak federates with existing Oracle OAM, no migration required
  • Token Exchange — RFC 8693 compliant token exchange for service-to-service calls
  • mTLS — Mutual TLS between Control Plane and Gateway components
  • RBAC — Role-based access control with tenant isolation

Secrets Management​

STOA integrates with HashiCorp Vault for secrets management:

  • Dynamic secrets generation for database credentials
  • Automatic credential rotation
  • Audit logging of all secret access
  • Kubernetes-native integration via CSI driver

Network Security​

LayerProtection
EdgeWAF integration, DDoS protection via Cloudflare
TransportTLS 1.3, mTLS for internal communication
ApplicationInput validation, rate limiting, circuit breakers
DataEncryption at rest (AES-256), field-level encryption for PII

Trust Boundary Architecture​

STOA implements a Zero Trust architecture with clearly defined security zones:

Zone Definitions:

  • External (Red) — Untrusted internet traffic, potential attackers
  • DMZ (Amber) — Semi-trusted zone with ingress controllers and gateways
  • Internal (Green) — Trusted zone with core services, databases, and message queues

Audit & Observability​

Audit Trail​

Every action in STOA is logged with:

  • Who — User identity, tenant, role
  • What — Action type, affected resources
  • When — Timestamp with microsecond precision
  • Where — Source IP, geographic location
  • Result — Success/failure, error details

Log Retention​

Log TypeDefault RetentionConfigurable
Access Logs90 daysYes
Audit Logs1 yearYes
Metrics13 monthsYes
Security Events2 yearsYes

Compliance Reporting​

Built-in dashboards for:

  • API usage by consumer/team
  • Authentication failures and anomalies
  • Data access patterns
  • SLA compliance metrics

Security Certifications (Roadmap)​

CertificationStatusTarget
SOC 2 Type IIPlannedQ4 2026
ISO 27001Planned2027
ISAE 3402Planned2027

Next Steps​