Okestreta LogoOKESTRETA

Choose and document the deployment boundary.

Okestreta supports deployment patterns that can be scoped for a client cloud account, an on-premises environment, or a dedicated managed environment. Tenancy, residency, encryption-key custody, operator access, and support boundaries depend on the selected architecture and contract.

Isolation is a deployment property.

Single-tenancy, dedicated resources, and network separation are not assumed across every deployment. The architecture review records what is isolated, who controls each layer, and which operational exceptions apply.

Tenancy Boundary

Select and document the compute, storage, and network separation required for the institution and use case.

Key Custody

Define key ownership, rotation, HSM compatibility, break-glass access, and any support-access exceptions in the security design.

Air-Gapped Option

Scope an air-gapped pattern only where the on-premises design and operating model support complete network separation. Review update and support trade-offs first.

Choose the deployment model through review.

Client-cloud, on-premises, and managed environments create different feature, control, support, and operating boundaries. Validate compatibility and responsibilities for the selected model before committing to production.
CLOUD

Your Cloud Account

Where supported, deploy into an approved client cloud account and region. Document provisioning access, operations ownership, data movement, and service dependencies in a responsibility matrix.
Proposed client cloud account
Region selected after legal and technical review
Agreed operating responsibility
ON-PREMISE

Your Data Centre

An on-premises deployment can be scoped where the institution requires infrastructure inside its data centre. Confirm feature compatibility, connectivity, patching, monitoring, and support access during design.
Documented firewall and network boundary
Air-gapped option subject to design
Customer-controlled operating environment
MANAGED

Dedicated Managed

A dedicated managed pattern can be scoped where Okestreta assumes agreed operating responsibilities. Resource boundaries, support coverage, maintenance, scaling, and security responsibilities are defined in the service schedule.
Resource boundary documented
Support hours agreed in contract
Maintenance ownership agreed

Security requirements must be evidenced.

Encryption

Specify encryption in transit and at rest, key custody, rotation, and operational access for the selected deployment. Record exceptions and approval paths.

Access Governance

Assess authentication, authorisation, field-level access, network restrictions, audit logging, SSO, and SIEM needs against the current deployment specification.

Access Model

Define trusted boundaries, roles, privileged access, session controls, and review procedures. Validate the implemented controls before production approval.

Resilience

Agree backup ownership, restore procedures, recovery objectives, and test frequency for the selected deployment. Numeric objectives require contractual scope and recovery-test evidence.

Map controls to the selected jurisdiction.

A deployment does not become compliant because a framework or regulator is named on a product page. The institution's legal, risk, and security teams identify the applicable requirements. The project then maps supported controls, gaps, evidence, and responsibilities for specialist review.

Banking

Map applicable prudential, outsourcing, data-residency, model-risk, and customer-treatment requirements with the institution's reviewers.

Insurance

Identify the applicable data, conduct, outsourcing, and model-governance requirements before selecting controls.

Pensions

Identify member-data, reporting, outsourcing, and governance requirements for the operating jurisdiction.

Mobile Money

Identify e-money, transaction-reporting, agent-network, customer-treatment, and data requirements with the institution's reviewers.

Data Protection

Identify the applicable law, lawful basis, residency, retention, deletion, and data-subject requirements. Then validate the selected technical and contractual controls.

Design evidence for the reviewers who need it.

The use case determines which decisions, recommendations, approvals, actions, model versions, and outcomes must be retained. Reporting and SIEM exports depend on the selected integration. Confirm the implemented record and retention boundary during the proof and security review.

Decision and Action Records

Define the actor, action, time, model version, policy context, and outcome fields required for the use case.

Evidence Exports

Define the reports, schedules, recipients, retention, and external-system interfaces required by reviewers.

Explainability Record

Specify reason codes, contributing signals, confidence, model version, and policy context for each governed recommendation.

Integrate with the stack you have.

During discovery, map the required systems, fields, interfaces, data quality, and approval path. Use batch, API, or event ingestion supported by the selected design. Read-only data access can reduce write-path risk when it is technically enforced, but it does not eliminate confidentiality, availability, performance, or operational risk.Confirm named systems, supported versions, connector availability, responsibilities, and the integration schedule during discovery. Timing depends on data readiness, interface access, security review, testing, and change windows.

Assess your deployment requirements.

Assess Deployment Fit