Home › O-PAS for EPCs › Responsibility Matrix
EPC Delivery · Integration Authority · Commercial Clarity
O-PAS responsibility matrix for EPC projects
A practical framework for assigning architecture, integration, application, verification and handover responsibilities across the owner, EPC, system integrator and component suppliers.
The direct answer
Every O-PAS project needs one named accountable party for the integrated system and one responsible party for every interface, test and lifecycle artifact. Product conformance does not assign those responsibilities, and a multi-vendor architecture does not make them shared by default.
The matrix below is a starting point for a common delivery model: the owner defines the requirement, the EPC holds project delivery, a specialist system integrator performs architecture and integration work, and component suppliers remain accountable for their products and evidence.
01 · Commercial exposure
Why an O-PAS project needs an explicit responsibility matrix
A conventional DCS contract often places internal integration inside one supplier's product boundary. An O-PAS project may distribute functions across several suppliers, so work that was previously bundled becomes visible project scope.
Technical boundary
Who defines the target architecture, allocates requirements, approves interfaces and controls the integrated configuration?
Commercial boundary
Who carries the cost and schedule consequence when two individually acceptable components do not behave together as required?
Verification boundary
Who reviews product evidence, develops interoperability tests, witnesses FAT and decides whether corrective work is complete?
Lifecycle boundary
Who owns application source, interface definitions, configuration records, updates, support and future component replacement?
The commercial rule
If an activity has no accountable party, it is not shared scope. It is unassigned scope. During execution, unassigned scope usually lands with the party holding the schedule.
02 · Role definitions
What each party owns in the default EPC model
Owner
Defines the business and operating requirements, names applicable standards and profiles, establishes cybersecurity and acceptance requirements, and accepts the delivered system.
EPC
Holds project delivery accountability, incorporates O-PAS scope into the contract and schedule, coordinates suppliers, approves project deliverables and manages change.
System integrator
Translates requirements into architecture, defines and integrates interfaces, develops or coordinates applications, manages integrated configurations and leads system-level verification.
Component supplier
Delivers the specified product, documentation, supported interfaces, configuration guidance, product evidence, defect correction and specialist support within its contracted boundary.
Accountable means the single party answerable for the outcome. Responsible means the party performing the work. Several parties may contribute, but each activity should have only one accountable party.
03 · Working matrix
Illustrative O-PAS responsibility matrix
A Accountable · R Responsible · C Contributes or is consulted · — Not typically involved
| Activity | Owner | EPC | System integrator | Component supplier |
|---|---|---|---|---|
| Define business, operating and lifecycle requirements | A/R | C | C | — |
| Identify applicable O-PAS requirements and profiles | A | C | R | C |
| Translate the owner requirement into project scope | C | A | R | C |
| Define the target system architecture | C | A | R | C |
| Allocate requirements to components and suppliers | C | A | R | C |
| Perform technical bid evaluation | C | A | R | C |
| Provide product conformance and technical evidence | — | C | C | A/R |
| Define interfaces and information models | C | A | R | C |
| Deliver and support component interfaces | — | C | C | A/R |
| Develop and manage control applications | C | A | R | C |
| Integrate the multi-supplier system | C | A | R | C |
| Define owner cybersecurity requirements | A/R | C | C | — |
| Implement project cybersecurity architecture | C | A | R | C |
| Control integrated configuration and versions | — | A | R | C |
| Review product conformance evidence | C | A | R | C |
| Develop interoperability test procedures | C | A | R | C |
| Execute integrated FAT and manage retest | C | A | R | C |
| Define final project acceptance criteria | A/R | C | C | — |
| Execute SAT, commissioning and cutover | C | A | R | C |
| Approve lifecycle handover package | A | R | R | C |
| Provide post-handover product support | C | — | C | A/R |
This matrix is illustrative. The contract must adapt it to the selected delivery model, architecture, owner capability, supplier scope and acceptance process. The purpose is to expose gaps before award, not to prescribe a universal allocation.
04 · Contracting model
How the responsibility split changes
| Delivery model | Likely integration authority | What the contract must make explicit |
|---|---|---|
| EPC-led delivery | EPC accountable; specialist integrator responsible. | Integrator authority, supplier cooperation obligations, issue escalation and acceptance recommendations. |
| Owner-led integration | Owner's automation organization. | Owner-furnished architecture and interfaces, EPC reliance, decision timing and responsibility for owner-directed changes. |
| Independent integrator contract | System integrator accountable under a direct owner contract. | Contractual interfaces between EPC and integrator, schedule authority, shared deliverables and change control. |
| Principal supplier-led package | Principal supplier within a defined package boundary. | What remains outside the package, treatment of third-party components, evidence obligations and system-level acceptance. |
The invariant
The allocation can change. The need for one accountable integration authority does not. A responsibility matrix should describe the actual contracts, not the organizational chart the project wishes it had.
05 · Interface ownership
Assign both sides of every interface
An interface is not owned merely because one supplier exposes it. The project needs responsibility for the definition, each endpoint, integrated behavior, testing and correction.
| Interface decision | Required assignment |
|---|---|
| Definition | Who approves data, semantics, performance, security and failure behavior? |
| Endpoint A | Who configures, documents and supports the first component? |
| Endpoint B | Who configures, documents and supports the second component? |
| Integrated behavior | Who is accountable for the two endpoints operating together? |
| Verification | Who writes, executes, witnesses and accepts the interface test? |
| Correction | Who diagnoses the fault, coordinates suppliers, pays for correction and authorizes retest? |
| Lifecycle | Who controls compatible versions, changes, replacements and regression testing after handover? |
Use the O-PAS Project Estimating Guide to classify interfaces and price the associated engineering, test and correction effort.
06 · Project controls
Documents that make the matrix operational
Requirements allocation
Maps each owner and O-PAS requirement to a component, supplier, verification method and acceptance record.
Interface register
Names both endpoints, interface owner, definition status, test method, issue status and lifecycle authority.
Conformance evidence register
Records the product, version, claimed profile, published evidence, reviewer and any project requirement not covered by that evidence.
Verification responsibility matrix
Assigns procedure development, environment, execution, witnessing, acceptance, correction and retest for every test class.
Decision and escalation map
Defines technical authority, response times and escalation routes when suppliers disagree or a boundary fails.
Lifecycle handover matrix
Assigns creation, review, acceptance and future ownership of source, configurations, licenses, records and support obligations.
07 · Bid and contract gate
Responsibility review checklist
Final contract question
If two components satisfy their individual supplier obligations but fail the project's interoperability test, does the contract identify who diagnoses the problem, directs the correction, pays the cost and accepts the retest? If not, the responsibility matrix is incomplete.
Primary references
Standards and certification sources
- The Open Group Open Process Automation Forum — the forum responsible for the O-PAS Standard.
- The Open Group O-PAS Certification Program — certification scope and program information.
- The Open Group O-PAS Certification Register — public register of certified products.
This guide is a project-delivery framework, not a substitute for the applicable contracts, owner specification, O-PAS Standard profiles or project-specific legal and commercial review.
Frequently asked questions
O-PAS project responsibility questions
Who should own system integration on an O-PAS project?
One party must be accountable for the integrated system. In an EPC-led model, the EPC commonly retains accountability while a specialist system integrator performs the architecture and integration work. Other models can work, but the authority, contractual interfaces and acceptance role must be explicit.
Does an O-PAS component supplier own interoperability?
A supplier owns its contracted product behavior, supported interfaces and evidence. Project interoperability spans multiple components in a specific architecture and configuration, so the project must separately assign accountability for integrated behavior, testing and issue resolution.
Is product conformance enough to assign responsibility?
No. Product conformance is evidence about a product against specified requirements or a named profile. It does not assign project scope, guarantee system interoperability or replace contractual acceptance criteria.
What is the EPC accountable for?
In the default model shown here, the EPC is accountable for translating the owner requirement into deliverable project scope, coordinating suppliers, approving architecture and project deliverables, managing integrated verification, controlling change and delivering the accepted system.
When should the responsibility matrix be completed?
Develop it during specification and bid review, qualify unresolved items in the proposal, and align it across contracts before award. Waiting until detailed engineering turns responsibility questions into change, delay and margin exposure.
What is the most important row in the matrix?
The integration authority. Without one accountable party for the integrated system, interface definition, issue resolution and acceptance can fragment across contracts even when every supplier fulfills its individual scope.
Before the responsibility split reaches the contract
Close the gaps while they are still clarification questions
CSI helps owners and EPC teams turn O-PAS requirements into an architecture, responsibility matrix, interface register and verification basis that can be estimated and contracted.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. The Open Process Automation Forum (OPAF) is a forum of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard; references to O-PAS on this page do not imply certification, affiliation or endorsement by The Open Group.