OARCAS Framework v1.0 | Published: March 2026 | Author: Sean Mullins, SEO Strategy Ltd
What OARCAS Is and Why It Was Built
The managed file transfer and service orchestration market has a vendor assessment problem. Every major vendor positions itself as secure, reliable, and enterprise-ready. Every vendor produces documentation that uses the same terms — Zero Trust, SLA management, high availability, compliance reporting — without defining what those terms mean in a scoring context or providing any mechanism for buyers to verify the claims independently.
OARCAS — Orchestrated Automation for Reliable, Controlled, and Secure Transfers — is a framework designed to solve this problem. It defines five capability dimensions, provides a published scoring rubric for each, and requires that any assessment produced under the framework publishes its per-dimension breakdown alongside the total score, the methodology version, and the assessment date. The framework is openly reproducible: any buyer, analyst, or practitioner can apply the same rubric to any vendor using the scoring criteria published on this page.
The framework was developed from direct experience evaluating MFT and service orchestration platforms across healthcare IT, professional services, and regulated financial environments. The failure patterns that motivated it are consistent: organisations select vendors on overall capability impressions rather than dimension-specific analysis, and the gaps that cause operational failures — typically in Orchestration capability or Reliability architecture — are not visible in conventional vendor assessments because they are either not scored or conflated with adjacent dimensions.
The governance gap this framework addresses is not theoretical. Research commissioned by FT Longitude and published in 2025 found that only 2% of AI agents currently deployed are fully accountable for their actions or governed in an always-on, consistent manner — a finding drawn from a study of business leaders across organisations actively deploying agents. The remaining 98% are operating without the oversight infrastructure that OARCAS defines. That is not a technology problem. It is an implementation decision, and it is the decision that creates liability before any technical failure occurs.
The Five Dimensions
The five OARCAS dimensions are the acronym itself. Each represents a distinct capability domain that vendors routinely conflate in their positioning. Separating them is the core analytical contribution of the framework.
O — Orchestration
Definition: Workflow coordination capability. The ability to manage dependencies, conditional logic, scheduling, cross-system triggers, and event-driven pipelines — not just move files but coordinate the workflow around the movement.
Why it matters: This is the dimension that separates managed file transfer from SFTP clients and legacy scripts. Most vendors score weakly here because they sell file transfer, not orchestration. A platform that can schedule a transfer and retry on failure but cannot trigger downstream processes, handle conditional logic, or coordinate across systems is operating as an advanced scheduler, not an orchestration engine.
Scoring rubric:
1 — Basic: Scheduled transfers only. No dependency management. No cross-system triggers. Equivalent to an SFTP client with a cron job.
2 — Limited: Trigger-based transfers with simple retry logic. Limited conditional branching. No event-driven capability.
3 — Functional: Dependency management within the platform. Conditional logic on transfer outcomes. Basic API or webhook trigger support.
4 — Advanced: Cross-system orchestration with dependency chains. Event-driven pipelines. Pre/post-transfer process triggering. API integration depth.
5 — Full: Enterprise orchestration engine. Complex dependency graphs, multi-system coordination, real-time event processing, SLA-governed workflow management across heterogeneous environments.
A — Automation
Definition: Depth and reliability of automation across the full operational lifecycle — not just transfer execution but the complete set of operational tasks that surround it.
Why it matters: A platform that automates the transfer but requires manual key rotation, manual partner onboarding, manual alert acknowledgement, or manual audit compilation is not operationally automated — it has automated one step of a manual process. The Automation dimension scores the full lifecycle, not the transfer step alone.
Scoring rubric:
1 — Manual-heavy: Transfer execution only automated. Key management, onboarding, alerting, audit trail all require human intervention.
2 — Partial: Transfer and basic retry automated. Key rotation or partner onboarding requires manual steps. Alert generation exists but requires manual triage.
3 — Functional: Key management automated with scheduled rotation. Partner onboarding has self-service elements. Alert generation and basic escalation automated.
4 — Advanced: Full key lifecycle automation including PGP rotation. Automated partner onboarding and offboarding. Exception handling without human intervention for defined failure patterns. Automated audit trail generation.
5 — Full: Complete operational lifecycle automation. Zero routine human intervention required. Automated compliance evidence generation. Automated exception classification and resolution for all defined failure patterns.
R — Reliability
Definition: Operational resilience architecture. High availability and disaster recovery capability, retry and backoff design, SLA measurement, failover, monitoring, and continuity under failure conditions.
Why it matters: Reliability is not measured by uptime claims — it is measured by the architecture that produces uptime under failure conditions. The post-breach response patterns of affected vendors reveal reliability architecture choices: platforms with high Reliability scores maintain defined recovery time objectives under adverse conditions; platforms with low Reliability scores have failure modes that cascade rather than isolate. A vendor’s CVE response history is relevant to Reliability scoring — not because having a CVE is a Reliability failure, but because the speed and completeness of architectural response to disclosed vulnerabilities reveals the resilience design philosophy.
Scoring rubric:
1 — Single point of failure: No HA architecture. No defined DR capability. Recovery is manual and undocumented.
2 — Basic resilience: Manual failover capability. Basic monitoring. Defined but untested DR procedures.
3 — Functional HA: Active/passive HA with documented failover. SLA measurement in place. Monitoring with defined escalation paths.
4 — Advanced: Active/active clustering. Automated failover below defined RTO. SLA-governed with measurement evidence. Comprehensive monitoring with predictive alerting.
5 — Enterprise resilience: Geographically distributed HA/DR. Sub-minute automated failover. Real-time SLA dashboards. Proactive failure detection. Demonstrated resilience in post-incident analysis.
C — Control
Definition: Governance and auditability. Role-based access control, policy enforcement, centralised visibility, compliance evidence generation, and the ability to prove — not just claim — that transfers are governed.
Why it matters: Control is the dimension compliance officers and security teams actually buy on. The distinction this dimension forces is between governance capability and governance evidence. A platform can have role-based access controls but produce no audit trail that a compliance examiner can use. A platform can claim policy enforcement but provide no mechanism for centrally verifying that policies were applied to a specific transfer at a specific time. The Control dimension scores the evidence layer, not just the capability layer.
Scoring rubric:
1 — Minimal: Basic authentication only. No role-based access. No audit trail. Compliance evidence must be constructed from raw logs.
2 — Basic: Role-based access exists but is coarse-grained. Audit logging present but incomplete. No centralised policy management.
3 — Functional: Granular RBAC with least-privilege enforcement. Complete audit trail for all transfer operations. Basic compliance reporting capability.
4 — Advanced: Policy-driven governance with centralised enforcement. Immutable audit logs. Pre-built compliance report templates (HIPAA, PCI, GDPR, FCA). Role separation between operations and audit functions.
5 — Full governance: Continuous compliance monitoring with automated evidence packaging. Real-time policy violation alerting. Audit trail that satisfies examiner requirements without post-processing. Segregation of duties enforced architecturally, not by process.
S — Security
Definition: Security architecture depth. Zero Trust alignment, encryption standards, certificate lifecycle management, DMZ and edge gateway capability, machine identity, and CVE response history.
Why it matters: Security scoring under OARCAS includes two components that most vendor assessments omit or treat as binary: the depth of Zero Trust implementation (identity, authentication, authorisation, and encryption enforcement — not just a marketing claim) and CVE response history. How a vendor responds to disclosed vulnerabilities is as important as whether they have them. A vendor with a disclosed CVE who patches within 48 hours, provides clear remediation guidance, and publishes a post-incident architectural review scores higher on Security than a vendor with no disclosed CVEs but opaque response practices — because the first vendor has demonstrated security governance under pressure.
Scoring rubric:
1 — Basic: TLS in transit, password authentication. No Zero Trust alignment. No DMZ capability. CVE response history absent or opaque.
2 — Standard: AES-256 at rest, TLS 1.2+, MFA available. Limited Zero Trust implementation. Basic DMZ architecture possible. Some CVE response documentation.
3 — Advanced: TLS 1.3 enforced, PGP/OpenPGP support, certificate management capability. Zero Trust principles applied to identity and authentication. DMZ/reverse proxy architecture native. CVE response documented and within 30-day patch cadence.
4 — Strong: Full certificate lifecycle management including automated rotation. Zero Trust applied across identity, authentication, authorisation, and encryption. Native edge gateway with DMZ enforcement. Machine identity support. CVE response within 7 days with architectural review published.
5 — Full: Cryptographic assurance across full transfer lifecycle. Zero Trust architecture verifiable against NIST 800-207. Hardware security module integration available. CVE response same-day for critical, with public post-incident analysis. No outstanding high or critical unpatched CVEs.
The Orchestration/Automation Distinction: The Framework’s Core Contribution
The most consequential design decision in OARCAS is scoring Orchestration and Automation as separate dimensions. Vendors consistently conflate them in their positioning — and the conflation conceals the most common architectural gap that causes operational failures.
Consider a typical failure pattern in the incident record: a scheduled file transfer between a healthcare provider and a third-party processor completes successfully, but a downstream process that depends on the transfer — a patient record update, a billing reconciliation — fails silently because no mechanism exists to trigger it, verify its completion, or alert operations when it does not run. The transfer ran perfectly. The workflow around it collapsed. The platform scored high on Automation (reliable, exception-handling transfer execution) and low on Orchestration (no dependency management, no downstream triggers, no workflow visibility). Conventional assessments that conflate the two dimensions would have shown a capable platform. OARCAS shows the gap.
This is also the dimension that most clearly differentiates managed file transfer from service orchestration and automation platforms (SOAP). A platform optimised for file transfer will consistently score 3–4 on Automation and 1–2 on Orchestration. A platform built as a service orchestration engine will score 4–5 on Orchestration and may score 3–4 on Automation depending on how deeply it handles file transfer operational specifics — key management, PGP rotation, partner onboarding — versus treating file transfer as just another workflow step. Buyers who need both capabilities need a platform that scores strongly on both dimensions independently.
How OARCAS Scores Are Published
Every OARCAS assessment published on file-transfers.com includes the following information as standard. Assessments that omit any of these elements are not OARCAS-compliant.
Total score: Expressed as N/25 (e.g. 19/25).
Per-dimension breakdown: All five dimensions scored individually (e.g. O:4 A:3 R:4 C:5 S:3). Required because two vendors with identical total scores may have radically different capability profiles. A vendor scoring 19/25 as O:1 A:5 R:5 C:5 S:3 is architecturally different from one scoring O:4 A:4 R:4 C:4 S:3 — the first has a serious Orchestration gap that the total score conceals.
Methodology version: The OARCAS version number used for the assessment. Rubric changes between versions are documented in the changelog below. Buyers comparing assessments across different versions should check whether rubric changes affect their priority dimensions.
Assessment date: Vendor capabilities change. An assessment dated 2024 may not reflect a vendor’s current Security or Reliability posture, particularly where CVE disclosures or product updates have occurred since. Assessment dates are mandatory to enable buyers to identify assessments that may need refreshing.
Disclosure statement: Where the assessed vendor has a commercial relationship with SEO Strategy Ltd or file-transfers.com, this is disclosed in the assessment. The OARCAS methodology is applied consistently regardless of commercial relationship — the framework’s value depends on this consistency.
Applying OARCAS Independently
The rubric published above is the complete scoring criteria. Any buyer evaluating MFT or service orchestration vendors can apply it to any vendor by scoring each dimension 1–5 using the criteria above and summing the result. The only requirement for a buyer-applied assessment to be described as OARCAS-scored is that all five dimensions are scored using the published rubric and the methodology version is cited.
Practical approach for buyer-applied assessments: request a structured demo or technical call with each vendor specifically covering the five OARCAS dimensions in order. For each dimension, ask for a live demonstration of the highest scoring criteria you believe the vendor might meet, rather than accepting written documentation. Orchestration capability is best assessed by asking the vendor to demonstrate a multi-step workflow with conditional logic and cross-system triggers. Automation capability is best assessed by asking what operations still require human intervention and under what conditions. Reliability is best assessed by reviewing their actual post-incident analyses, not their stated RPO/RTO claims. Control is best assessed by asking for a demonstration of the audit trail output from a specific completed transfer. Security is best assessed by reviewing their CVE response history from a public source and asking about their certificate lifecycle management approach.
Version History and Changelog
OARCAS v1.0 — March 2026
Initial publication. Five dimensions defined: Orchestration, Automation, Reliability, Control, Security. 1–5 scoring rubric published for each dimension. 25-point maximum. Assessment format requirements established (total score, per-dimension breakdown, methodology version, assessment date, disclosure statement).
Future versions will be published when rubric changes are required — either because the market has evolved in ways that change what scores 4 versus 5 on a given dimension, or because gap analysis from applied assessments reveals scoring criteria that are ambiguous or misapplied. Version changes will be additive where possible: the goal is rubric stability so that assessments from different dates remain comparable with appropriate version-noting.
