RACI
This page lists every activity in the Dedicated deployment model, where Akka owns and operates the cloud account and runs the platform within it. Dedicated is BYOC with the cloud-account layer re-owned by Akka, so most activities match BYOC, with the account, networking, and account-security rows owned by Akka.
The four RACI roles:
-
R (Responsible): the party that does the work.
-
A (Accountable): the party ultimately answerable for the outcome.
-
C (Consulted): the party whose input is sought before or during the work.
-
I (Informed): the party kept up to date on progress or results.
Each role cell uses one of the following values: C = Customer, A = Akka, ± = Akka and Customer, blank = not applicable.
Filter by layer or owner, or search across activity, description, and cadence. Owner is derived from the Responsible column: Customer, Akka, or shared.
General
| Sub-category | Activity | R | A | C | I | Description | Cadence |
|---|---|---|---|---|---|---|---|
Scope |
Shared Responsibility |
C |
C |
Anything not explicitly listed in this RACI is the Customer’s responsibility. This includes the customer application code, customer-side operational tooling, and any concern not explicitly assigned to Akka in the rows below. The Customer may request additional operational support from Akka via the standard support channel. |
Infrastructure
| Sub-category | Activity | R | A | C | I | Description | Cadence |
|---|---|---|---|---|---|---|---|
Cloud Account |
Billing & Ownership |
A |
A |
C |
Akka owns and operates the dedicated cloud account and pays the associated bill. The customer’s cost is set by an agreed structure. |
||
Cloud Account |
Provisioning |
A |
A |
C |
Akka provisions and owns the dedicated cloud account it operates in for hosting the Platform, and sets up the account infrastructure and access it needs to run the region. |
||
Cloud Account |
Quotas & Service Limits |
A |
A |
C |
Akka ensures sufficient quota based on usage for compute, storage, etc. in the cloud account it owns; the Customer is consulted on expected usage. |
||
Cloud Account |
Akka Permissions |
A |
A |
C |
Akka creates and maintains its own permissions within the Cloud Account it owns and operates, managing all IAM roles and bindings required for Platform operation. |
||
Cloud Account |
Dedicated Account for Akka |
A |
A |
C |
Akka provisions and operates a dedicated Cloud Account exclusively for the Platform. To prevent management conflicts, no additional resources are provisioned in this account. |
||
Networking |
Private Connectivity |
A |
A |
C |
Akka operates connectivity within its own VPC. Where the Customer integrates their own network (for example, a transit gateway), the parties coordinate on the integration. |
||
Networking |
Ingress/Egress Connectivity |
A |
A |
C |
AAO installs the load balancer and certificate issuer (Let’s Encrypt by default) for the region’s platform APIs and generated application hostnames. Where private connectivity is used, the load balancer uses an automatically generated IP so internal traffic does not traverse the public internet. |
||
Networking |
IP Address Management / CIDR Range Allocation |
A |
A |
C |
Akka assigns an appropriately sized CIDR block for the account it owns where peering or hub and spoke is desired. The Customer is informed. |
||
Networking |
IP Allowlist |
A |
A |
C |
Akka maintains the IP allowlist for the dedicated deployment, using the ranges the Customer provides. |
||
Networking |
DNS |
A |
A |
C |
Akka creates and maintains DNS records for platform machinery and apps in the cloud provider DNS zones for the installation in the account it owns. The Customer is informed. |
||
Maintenance |
K8s / DB Upgrades |
A |
A |
C |
The Kubernetes cluster and database are infrastructure Akka operates in the dedicated cloud account. Akka aims to perform upgrades within the preferred maintenance window and notifies the Customer prior to any maintenance that causes downtime. |
||
Operations |
Cost Controls |
A |
A |
C |
Akka pays the cloud bill in Dedicated and periodically reviews the cloud account subscription and monthly charges. Akka auto-provisions and maintains the cloud infrastructure and overhead required to run an Akka region. Automatic provisioning and de-provisioning of compute instances to accommodate utilization demand. Storage for the underlying persistence store scales automatically; its compute does not. Akka has various sizing options to keep costs in check but HA is the default. Akka provides cost and usage visibility to help the customer manage their spend. |
||
Cloud/Infrastructure Audit Logging |
Infrastructure Security Audit Logs |
A |
A |
C |
Akka collects and retains the cloud infrastructure security audit logs for the dedicated account and investigates suspicious activity, sharing relevant findings with the Customer. Feeds into Akka’s SIEM / security monitoring. |
||
Cloud/Infrastructure Audit Logging |
SIEM / Security Monitoring |
A |
A |
C |
Akka operates SIEM and security monitoring for the dedicated cloud account and notifies the Customer of relevant findings. |
||
Cloud/Infrastructure Audit Logging |
Cloud Security Posture |
A |
A |
C |
Akka owns cloud security posture management (security-service configuration and guardrails) for the dedicated account. |
||
PKI |
Customer Managed Database Encryption Keys |
C |
C |
A |
A |
The Customer creates and maintains the key material for the CMEK and shares its identifier with Akka. Customer is responsible for ensuring access to the CMEK |
|
PKI |
Customer-Provided TLS Certificates |
C |
C |
C |
Where the Customer brings its own domain, the Customer provides TLS certificates or configures cert-manager, and Akka validates and deploys them. See https://doc.akka.io/operations/tls-certificates.html#_custom_server_certificates for details. |
||
Backups and Recovery |
Database Point-in-Time Recovery (PITR) |
A |
A |
C |
Akka enables continuous point-in-time recovery for the database and notifies the Customer once configured. |
8-day retention |
|
Backups and Recovery |
Velero Used for K8s Resources |
A |
A |
Akka uses Velero to back up stateful Kubernetes resources so they can be restored. |
|||
Backups and Recovery |
Backup Restore Testing |
A |
A |
C |
Akka performs periodic restore testing against backups; results are summarized on request. |
||
Permissions |
Infrastructure Access Control and IAM |
A |
A |
C |
Akka owns account-level IAM for the dedicated cloud account where the region is installed. |
||
Permissions |
Service Accounts & Keys (Akka-managed) |
A |
A |
Akka creates and manages the service accounts, service account keys, and IAM bindings required for Platform operation within the Customer’s cloud account. |
Akka runtime & operators
| Sub-category | Activity | R | A | C | I | Description | Cadence |
|---|---|---|---|---|---|---|---|
Setup |
Bootstrapping Platform |
A |
A |
C |
A |
The Customer reviews Akka’s default networking, compute, and persistence configuration, and recommends changes to improve app performance, optimize costs, or address other concerns. |
|
Setup |
Federation via Teleport |
A |
A |
Akka installs the Teleport identity-aware proxy that is used for federation. |
|||
Setup |
Akka Region Group |
C |
C |
A |
A |
The Customer identifies region groups based on their use case and informs Akka. |
|
Setup |
Region Group Configuration |
A |
A |
C |
Akka configures region groups on the Federation Plane based on the Customer’s region groups configuration |
||
Setup |
Maintenance Window |
C |
C |
A |
A |
The Customer provides a preferred maintenance window. Akka aims to use this window for operations that may cause downtime, including database minor updates (applied automatically by the cloud provider) and manual upgrades such as database major patches. |
|
Maintenance |
Akka Runtime & Operators Patching / Vulnerability Management |
A |
A |
C |
Akka patches and remediates vulnerabilities in the Akka runtime & operators and the infrastructure it operates in your cloud account: the JVM, container base image, operating system, and Akka runtime that ship with the customer’s deployed services. Vulnerability reports are available from Akka’s trust center. |
||
Maintenance |
Releases |
A |
A |
C |
Akka schedules regular releases to installations, which can include the Runtime, Region machinery, and Federation Plane. |
||
Operations |
Scalability |
± |
± |
± |
Scaling of compute instances and storage for the underlying persistence store. Akka monitors utilization and concurrency demand and auto-scales accordingly within Akka’s defined sizing standards. The Customer should notify Akka in advance if they expect rapid expansion or need pre-warming for performance testing or spiky loads. |
||
Operations |
Your Akka App Elasticity |
A |
A |
C |
C |
Akka dynamically adds and removes compute and persistence to accommodate real-time traffic against the Customer’s performance SLA targets. |
|
Operations |
Akka Region Decommission |
A |
A |
C |
C |
When the Customer requests removal of a Region (e.g., end of contract, scope change, or topology adjustment), Akka follows the documented decommissioning runbook to gracefully remove the Region from the Federation Plane and clean up stale resources. |
|
Operations |
Feature Requests |
C |
C |
A |
C |
The Customer submits feature requests via the support channel. Akka triages, prioritizes, and communicates status. |
|
Observability |
Platform Logs Excluding SDK Logs |
A |
A |
Akka monitors all Platform logs except for SDK logs. |
30-day retention |
||
Observability |
Availability |
A |
A |
Akka monitors and reports availability of the Akka Platform, with uptime reports available on request. Platform availability commitments are governed by the Akka Federation Plane SLA Policy. Availability of customer-deployed services running on the platform is the Customer’s responsibility; see the Services layer. |
|||
Observability |
Akka Region Telemetry |
A |
A |
C |
Akka monitors metrics and logs and will notify the Customer as needed. |
||
Observability |
Application Telemetry Export |
C |
C |
A |
The Customer configures export of application logs and metrics to its observability platform via Akka SDK integration patterns. |
||
Backups and Recovery |
Disaster Recovery Validation |
A |
A |
C |
Akka periodically validates disaster recovery for the platform it operates. Joint exercises with the Customer can be arranged as agreed. |
As agreed |
|
Backups and Recovery |
Cross-Region Replication Configuration |
± |
± |
C |
The Customer specifies replication mode (e.g., region-pinned, replicated) per service. Akka enables and operates the underlying replication. |
||
Backups and Recovery |
Multi-Region Failover Procedure |
A |
A |
C |
C |
Akka operates the failover tooling and runbooks. The Customer is consulted before failover and informed of execution. |
|
Backups and Recovery |
Recovery Time / Point Objectives |
A |
A |
C |
C |
RTO/RPO targets are defined in the Customer’s agreement. |
|
Developer Experience |
SDLC Tooling Procedures |
C |
C |
The Customer owns and operates the SDLC environment used to build services running on Akka, including IDE choices, source code repository, CI/CD pipelines, and developer programming environments. Akka ships developer tooling that the Customer integrates into the SDLC: IDE AI assistants, a local development environment, unit and integration testing utilities, and deployment configuration / deployment tooling. |
|||
Permissions |
Access-Control Reports |
A |
A |
Akka provides access-control reports for the Customer’s installation on request. Database-level audit logging is also available where required. |
On request |
||
Permissions |
Just-in-Time Access for Customer Data |
A |
A |
C |
Where access to customer-confidential data is required (e.g., for incident handling), Akka requests authorization per the Access Control for Customer-Confidential Data policy. Audit logs of such access are available to the Customer on request. |
||
Permissions |
MFA on Akka Console & CLI |
C |
C |
A |
The Customer’s IDP enforces MFA for users accessing Akka console and CLI. Akka enforces MFA on its own internal access. |
||
Permissions |
Privileged Access via Teleport |
A |
A |
C |
Akka uses Teleport for human access to platform infrastructure, with session recording and audit logging. Access requires explicit justification and approval per Akka’s Access Control Policy. Teleport audit logs are available to the Customer on request. |
||
Compliance |
GDPR Requirements / Data Management |
C |
C |
Customer is responsible for how services handle PII and to ensure such handling is compliant with GDPR (or other applicable privacy regulations). Akka acts as neither controller nor processor of data handled by the Customer’s services. |
Federation Plane
| Sub-category | Activity | R | A | C | I | Description | Cadence |
|---|---|---|---|---|---|---|---|
Security |
Akka IAM Integration |
A |
A |
C |
C |
Akka Federation Plane integrates with the Customer’s identity provider to manage organizations, users, and team access controls. Application-level access scoping is handled separately via ACLs and tokens (see Services, Security, Service ACLs). |
|
Security |
IAM (CLI and Console) |
C |
C |
The Customer provides enterprise identity, authentication, and authorization systems and policies. |
|||
Procedures |
Disaster Recovery |
A |
A |
C |
C |
Akka maintains uptime for the Federation Plane and configures disaster recovery for it. |
|
Procedures |
Support and Communication Channels |
± |
± |
At onboarding, Akka and the Customer agree on operational and engagement-level communication channels for routine collaboration (e.g., shared Slack channels, email distribution lists, regular review cadence). Formal support and incident channels are governed separately by the Customer Support Policy and the Incident Response row. |
|||
Procedures |
Incident Response |
A |
A |
C |
Akka provides 24/7 incident response per the Customer Support Policy. The Customer opens incidents through the Customer Support Portal (support.akka.io), Akka Console (console.akka.io/support), or by email to [email protected]. Severity classifications, response time SLOs, escalation procedures, and incident communication protocols follow Akka’s Customer Support Policy and Incident Management Process. Other shared channels (e.g., Slack) may exist for ongoing engagements but are not a substitute for formal support cases. |
Per Customer Support Policy |
|
Procedures |
Postmortem Delivery |
A |
A |
Akka delivers post-incident reviews for Severity 1 and 2 incidents within an agreed cadence following resolution. |
|||
Procedures |
Maintenance Notifications |
A |
A |
C |
Akka notifies the Customer in advance of planned maintenance windows that could affect availability, and via release notify emails for runtime/SDK releases. Maintenance windows should be set in advance by the Customer. |
Per Customer Support Policy |
|
Procedures |
Operations Sync |
A |
A |
C |
C |
Recurring operational review covering system health, maintenance, incidents, and roadmap items relevant to the Customer. |
|
Procedures |
Strategic Steering |
A |
A |
C |
C |
Periodic alignment session covering usage, capacity, product direction, and Customer priorities. |
|
Procedures |
Executive Partnership Review |
A |
A |
C |
C |
Executive-level partnership review covering relationship health, escalation status, and strategic items. |
|
Procedures |
Dedicated Onboarding |
± |
± |
C |
Joint onboarding covering account setup, Region provisioning, connectivity validation, and acceptance criteria. |
||
Procedures |
Customer Portal Access & Training |
± |
A |
C |
C |
The Customer is assigned access to the Portal. Akka assigns their Region and walks them through console and CLI usage, and ticketing flow. |
|
Procedures |
Customer User & Team Management |
C |
C |
C |
The Customer manages its own users, teams, and role assignments within the Akka console. |
||
Procedures |
Customer Offboarding & Data Return |
± |
± |
At end of contract, Akka coordinates region decommission, return or destruction of customer data, and revocation of access per the Data Retention Policy. |
Per agreement |
||
Procedures |
Issue Tracking |
A |
A |
C |
Akka tracks Customer-raised issues and remediation through to closure with status visibility to the Customer. |
||
Compliance |
Security Questionnaire Response |
A |
A |
C |
Akka responds to Customer CAIQ/SIG and bespoke security questionnaires drawing on the ISMS control library. |
||
Compliance |
Data Breach Notification |
A |
A |
C |
Akka notifies the Customer without undue delay where a breach of Akka-held customer data poses risk, including nature, scope, and remediation. |
||
Compliance |
Sanctions Screening |
A |
A |
C |
Customer organizations are screened against sanctions lists periodically. The Customer is informed if a screening result requires action. |
||
Compliance |
End-of-Life Notification |
A |
A |
C |
Akka provides advance notice of any planned product or feature EOL with sufficient lead time for migration planning. |
||
Compliance |
Encryption in Transit and at Rest |
A |
A |
Akka encrypts customer data in transit (TLS) and at rest using cloud provider encryption services. Default keys are Akka-managed. |
|||
Compliance |
Cryptographic Key Management |
C |
C |
A |
Lifecycle, rotation, and access control of cryptographic materials follow the Akka Key Management and Cryptography Policy. Cloud-native KMS handles lifecycle for Akka-managed materials. Customer-managed keys (CMEK, BYO certificates) are managed by the Customer per the same policy. |
Per Key Management and Cryptography Policy |
|
Compliance |
Vulnerability Scanning |
A |
A |
C |
Akka performs continuous vulnerability scanning of platform components and dependencies; findings are tracked to remediation per the Vulnerability Management Policy. Customers are notified of critical and high severity security patches via security advisory emails and the trust center. Disclosure occurs no later than the date the patch is made available, with coordinated advance notice to affected customers where applicable. |
||
Compliance |
Personnel Security & Background Checks |
A |
A |
C |
Akka performs background checks on personnel with access to customer environments and provides security awareness training, per the Personnel Security Policy. |
Annual access certification |
|
Compliance |
SOC 2 Type II |
A |
A |
Akka maintains SOC 2 Type II for the Akka Platform. Report available under NDA via trust.akka.io. SOC 3 is also available as a publicly-shareable companion. |
Annual report; trust.akka.io kept current |
||
Compliance |
Data Residency |
A |
A |
Customer data is stored within the cloud region(s) configured for the customer’s installation. Multi-region installations replicate within customer-selected regions only. Each customer’s data is isolated in dedicated database resources; no shared data plane across customers. |
|||
Compliance |
Multi-Tenant Data Security |
A |
A |
Akka is responsible for securing all customer data located within the Federation Plane. |
|||
Compliance |
Customer Data Security |
C |
C |
The Customer is responsible for securing Federation Plane tokens and access to projects. |
|||
Compliance |
GDPR Requirements / Data Management |
± |
± |
The Federation Plane doesn’t handle any customer data; it processes only minimal PII consisting of customer user and administrator identities, which is handled in accordance with Akka’s GDPR-compliant privacy policy. |
|||
Compliance |
Subprocessor List |
A |
A |
Current subprocessor list maintained at trust.akka.io. |
trust.akka.io kept current |
||
Compliance |
Penetration Testing |
A |
A |
Annual third-party penetration testing conducted as part of SOC 2 audit cycle. Executive summary available under NDA via trust.akka.io. |
Annual |
||
Compliance |
Customer Audit Log Delivery |
A |
A |
Akka maintains audit logs of control-plane actions (e.g., authentication, project and service lifecycle, IAM and token changes). Logs delivered on request. Recurring delivery cadences can also be arranged. |
Services
| Sub-category | Activity | R | A | C | I | Description | Cadence |
|---|---|---|---|---|---|---|---|
Maintenance |
Application Code & Dependency Patching / Vulnerability Management |
C |
C |
The Customer reviews their application code and any libraries or dependencies they introduce for security issues and vulnerabilities. The JVM, container base image, OS, and Akka runtime packaged into the deployed service are patched by Akka (see Akka runtime & operators / Maintenance / Infrastructure patch / Vulnerability management). |
|||
Maintenance |
Service Configuration (incl. Secrets) |
C |
C |
The Customer configures services to enable their functionality, including secrets for accessing other services. |
|||
Maintenance |
Integrations Setup (Broker, Object Storage) |
C |
C |
Where services depend on integrations such as brokers or object storage, the Customer configures these for the Akka Project before service deployment. |
|||
Maintenance |
Deployments |
C |
C |
The Customer owns and manages the lifecycle of Akka SDK apps. |
|||
Maintenance |
Source Code Management |
C |
C |
Source code management for Akka Service implementations is the Customer’s responsibility. |
|||
Maintenance |
Scaling Limits |
C |
C |
The Customer controls service instance counts within configured limits. |
|||
Monitoring |
Logs from Services Built with Akka SDK |
C |
C |
Metrics and logs are sent to the Customer’s logging platform. Akka filters out logs at the source so they are not sent to Akka’s internal observability stack. |
|||
Monitoring |
SDK Logs |
C |
C |
The Customer monitors application logs. |
|||
Security |
Security Logs |
C |
C |
The Customer can configure dashboards over cloud security logs and stream them to a GSOC or observability tool. |
|||
Security |
Service ACLs |
C |
C |
The Customer configures Service ACLs to protect access to non-public service endpoints. |
|||
Permissions |
Application IAM |
C |
C |
Akka SDK supports access scoping through JWTs and JWKS. |