Architecture Reference  ·  v1.0

SODA Framework Architecture

A layered security model for enterprise offshore–onshore software delivery. Five control layers working together as a unified operating architecture.

Overview

An architectural approach to offshore delivery security


The SODA Framework (Secure Offshore DevSecOps Architecture) defines a layered security architecture for organisations operating offshore–onshore software delivery environments.

Modern engineering teams often include internal staff, offshore developers, external vendors, and cloud-based infrastructure spread across multiple regions. Traditional security frameworks were not designed for this level of geographic and organisational distribution, which results in inconsistent access control, weak pipeline integrity, and limited auditability.

The SODA Framework addresses this by defining five architectural layers that together create a secure, auditable, and scalable delivery model for multinational software development.

Architecture Diagram

The diagram below illustrates the layered structure of the SODA Framework and the control boundaries between offshore contributors and enterprise systems.

SODA Framework Architecture Diagram — Five-layer model

Figure 1 — SODA Framework v1.0 · Secure Offshore DevSecOps Architecture · sodaframework.org

The Five Layers

Each layer has a distinct security responsibility

All layers must operate together to produce a consistent and defensible delivery model. Security cannot be achieved by implementing only a single layer.

L1
Governance Layer
Who is allowed to do what, under what authority, and under what conditions?

The Governance Layer defines authority, policies, and operating rules across all participating teams. In offshore–onshore environments, development may involve employees, contractors, and external vendors working on the same systems. Without clear governance, security decisions become informal and inconsistent — making it impossible to enforce controls reliably or respond to incidents with confidence.

Security ownership Approval chains Vendor participation rules Geography-based restrictions Role definitions Policy enforcement
L2
Identity & Access Control Layer
Who can access which systems, from where, and with what restrictions?

The Identity and Access Control Layer enforces the authority defined by the Governance Layer. All access to repositories, cloud platforms, CI/CD systems, and production environments must be controlled through a unified identity model that applies equally to onshore employees, offshore developers, contractors, and vendors. Consistent identity enforcement prevents privilege sprawl and ensures that all actions can be traced to a verified user.

RBAC Multi-factor authentication Single sign-on (SSO) Privileged access management Device trust Geo-aware access Time-bound permissions
L3
Secure DevSecOps Pipeline Layer
How is software built, reviewed, scanned, and promoted securely?

The DevSecOps Pipeline Layer protects the integrity of software as it moves from development to production. In offshore–onshore environments, the pipeline becomes a critical security boundary because multiple teams may interact with the same repositories and deployment systems. The goal is to make the secure path the default path — integrating security controls into the delivery workflow in a way that is automated, auditable, and non-blocking for work that meets defined standards.

Branch protection Pull request approvals SAST / DAST scanning Secrets management Dependency scanning Build integrity Deployment gates
L4
Compliance & Audit Layer
Can the organisation prove that offshore delivery is secure and compliant?

The Compliance and Audit Layer ensures that security controls can be verified through logs, approvals, and audit records. The SODA Framework embeds auditability into the delivery architecture so that evidence is generated automatically during normal operation — not assembled manually before an audit. Without auditability, offshore delivery cannot meet enterprise security expectations from clients, regulators, or certification bodies.

Centralised logging Audit trails SOC 2 alignment ISO 27001 mapping Evidence retention Separation of duties Continuous verification
L5
Cross-Border Incident Response Layer
When something goes wrong, how does the organisation contain, investigate, and respond across borders?

The Incident Response Layer defines how security incidents are handled in multinational delivery environments. When teams, systems, and data are distributed across regions, incident response must account for jurisdiction, vendor involvement, and cross-border coordination. A secure delivery model must remain controllable even during unexpected events — and response procedures must be planned in advance, not improvised during an emergency.

Detection & escalation Containment Evidence handling Chain of custody Jurisdiction-aware response Vendor coordination Post-incident review
Design Principles

The architectural constraints behind every layer


The SODA Framework is based on seven core principles that determine how each layer is structured and how tradeoffs are resolved. These are not aspirational statements — they are design constraints.

P1
Security must be architectural, not ad hoc. Offshore security cannot depend on trust alone or informal controls assembled after the fact.
P2
Access must be explicit, minimal, and auditable. Every access path must be justified, scoped to what is required, and logged.
P3
Delivery speed must not bypass control integrity. Secure delivery should be the default operating mode, not a special process.
P4
Compliance must be embedded into delivery operations. Evidence must be generated continuously, not assembled before audits.
P5
Incident response must reflect multinational reality. Response procedures must account for jurisdiction and vendor boundaries.
P6
Governance must define authority across all teams. Authority must be explicit and enforceable before work begins.
P7
Layered architecture enables consistent enforcement. All layers must work together to produce a coherent security posture.
Learn More

For full technical details, read the whitepaper

The official whitepaper describes design principles, architecture layers, implementation model, and security responsibilities in full.