Learn how to structure a risk matrix in Engineering projects, define probability and impact criteria, classify criticality, treat risks, and monitor residual exposure.
Check it out!
A risk matrix is an assessment and prioritization technique that positions risks according to previously defined criteria of probability or likelihood and consequence for objectives. In Engineering projects, these objectives may involve schedule, cost, scope, technical performance, quality, safety, environment, compliance, availability, operation, contracting, and obligations toward third parties.
In practice, the matrix helps answer a management question: which exposures require immediate treatment, which need monitoring, and which can be accepted within the project’s criteria? It does not eliminate uncertainty, predict the future, or replace specialized technical analysis. Its function is to turn scattered assessments into a comparable decision logic.
The matrix is also not a universal formula. ABNT NBR ISO 31000 establishes principles, a framework, and a process for risk management, but it does not require a 5 × 5 matrix, fix a single scale, or determine a universal multiplication rule between probability and impact. Scales, criticality bands, and decision criteria must be calibrated to the context, objectives, and treatment capacity of the project.
For this reason, the quality of a matrix depends less on its colors and more on the traceability of the reasoning that led to the classification. A technically defensible assessment must make clear what may happen, why it may happen, which consequences are plausible, which controls already exist, what the current exposure is, who owns the risk, and what will be done next.
It is also useful to distinguish concepts that are often mixed together. Risk is the effect of uncertainty on objectives; an issue is a condition that has already occurred and requires action; a technical finding is an evidence-based observation; a nonconformity is failure to meet a requirement; and a hazard is a source or situation with the potential for harm. These elements may be related, but they are not synonyms.
Where the risk matrix fits in the risk management process
The matrix is a technique that supports analysis and evaluation, not the complete risk management process. ISO 31000 logic begins by defining scope, context, and criteria; proceeds to identification, analysis, and evaluation; continues to treatment; and remains connected to communication, consultation, monitoring, review, recording, and reporting.
This changes how the tool is used. Classifying a risk as “high” does not complete the work. The classification must trigger a decision compatible with the exposure: treat it, avoid a given condition, modify probability or consequence, share the exposure, accept it on an informed basis, or deepen the analysis when uncertainty remains material.
When an organization needs to structure this cycle permanently, the Engineering Risk Management service can integrate identification, assessment, treatment, contingency, and monitoring within project governance.
What a risk matrix needs to represent
The most common representation uses probability on one axis and consequence on the other. Each risk occupies a cell and receives a criticality class. This class may be expressed as levels — low, moderate, high, and critical, for example — or as numerical ranges associated with decision rules.
A useful matrix must preserve at least four elements of interpretation:
- risk event: what may occur;
- probability: how plausible the occurrence is within the analyzed horizon;
- consequence: which objectives may be affected and to what magnitude;
- decision criterion: what response or level of authority is required for that combination.
The last element is often forgotten. A matrix without a decision rule only classifies. If a “critical” cell does not require an owner, deadline, escalation, treatment, and monitoring, the color has little operational value.
In Engineering, the matrix must work together with the risk register, action plans, project decisions, and the evidence supporting the assessment. The visual chart is only one part of this system.
A matrix is reliable only when criteria are defined before scoring. If each discipline uses a different scale, criticality ceases to be comparable and prioritization loses value.
Before scoring: define scope, context, and criteria
The quality of scoring depends on what was defined beforehand. The same event may have different criticality in two projects because their objectives, tolerances, constraints, and consequences are different.
A five-day delay may be absorbable for an activity with float and extremely serious when it affects an industrial shutdown, an energization window, a regulatory milestone, or the critical path. Likewise, a cost variation considered small in a major program may be material in a lower-value contract.
Criteria should therefore be defined before specific risks are assessed. This reduces the bias of adjusting the scale to obtain a desired result and improves comparability among assessments.
The context of an Engineering project normally includes technical and business objectives, schedule and cost baselines, contractual limits, regulatory requirements, acceptance conditions, safety, operating environment, interfaces, resource availability, and the time horizon of exposure.
Requirements, Evidence, and Acceptance Criteria Management is directly related to this point. Weak risk criteria often begin with vague, untraceable requirements or requirements without an objective verification condition.
How to define the probability scale
Probability represents the likelihood of occurrence within a defined horizon. The scale may be qualitative, semiquantitative, or quantitative, but its levels must be interpretable and consistent among assessors.
Using only terms such as “rare,” “possible,” or “likely” can create divergence because each professional assigns a different meaning to those words. To reduce subjectivity, each level should have descriptors compatible with project reality and, whenever possible, objective references.
| Illustrative level | Interpretation | Evidence that may support the assessment |
| 1 — Rare | exceptional occurrence within the analyzed horizon | no precedents and robust controls |
| 2 — Unlikely | possible, but not expected | few comparable cases and low current exposure |
| 3 — Possible | plausible occurrence | precedents, signals, or conditions favorable to the event |
| 4 — Likely | occurrence expected under certain conditions | recurring history or insufficient controls |
| 5 — Almost certain | strong expectation of occurrence | current evidence, high recurrence, or a condition already developing |
The table is illustrative, not normative. In one project, descriptors may be associated with percentage ranges. In another, frequency, failure history, supplier maturity, material availability, requirement stability, or other suitable evidence may make more sense.
The technical point is that the number must represent a previously understood criterion, not an intuitive impression recorded after the discussion.
How to define the impact or consequence scale
Impact should not be treated as generic severity. A single event may affect several objectives at the same time. Delay of a critical piece of equipment, for example, may affect schedule, cost, mobilization, testing, contractual performance, and operating capability.
A more robust matrix distinguishes consequence dimensions and establishes specific descriptors for each one. The project then defines how to combine these dimensions or which one prevails.
| Dimension | Low | Medium | High | Critical |
| Schedule | absorbable by float | requires local replanning | affects a relevant milestone | compromises critical path or mandatory date |
| Cost | absorbable by routine management | requires reallocation | consumes significant contingency | threatens contractual limit or viability |
| Technical | no material functional effect | localized rework | degrades performance or requires redesign | prevents essential function or acceptance |
| Quality | minor correctable deviation | localized nonconformity | recurrence or process failure | compromises systemic compliance |
| Safety and environment | limited and controllable consequence | significant exposure | severe potential | intolerable consequence under applicable criteria |
| Contractual | no material effect | requires formalization | potential claim or penalty | compromises an essential obligation |
| Operations | no significant loss | localized degradation | significant unavailability | prevents operation or critical continuity |
Whenever possible, descriptors should be translated into measurable limits. For schedule and cost, percentages, days, or monetary values can reduce ambiguity. For safety, environment, or compliance, legal and regulatory criteria may require their own rules and prevent an intolerable consequence from being “diluted” by averaging other dimensions.
3 × 3, 4 × 4, or 5 × 5 matrix: which one to use?
There is no universally correct size. A 3 × 3 matrix is simpler, requires fewer distinctions, and may work well when information is limited or when the organization is still maturing its criteria. A 5 × 5 matrix offers greater granularity, but only adds value if assessors can consistently distinguish five probability levels and five consequence levels.
More cells do not automatically mean better analysis. A sophisticated matrix fed by vague criteria may produce false precision: the result appears mathematical, but the actual difference between a rating of 12 and 15, for example, may not be supported by the quality of the inputs.
The choice should consider data maturity, number of risks, discrimination capacity of the criteria, decision speed, and the consequence of incorrect classification.
For critical risks or high-value decisions, the matrix often works best as screening. The result indicates which exposures should proceed to more detailed analysis methods.
Probability × impact: is multiplication mandatory?
No. Multiplying scores is a widely used semiquantitative convention, but it is not a universal requirement of ISO 31000. If a team assigns probability 4 and consequence 5 and records “20,” that product only makes sense as an ordering mechanism if the scales, bands, and decision rules were designed for that use.
There is an important mathematical limitation: scales 1, 2, 3, 4, and 5 are normally ordinal. They rank categories, but do not guarantee that the distance between 1 and 2 equals the distance between 4 and 5. Therefore, the product should not automatically be interpreted as an exact physical quantity.
Another difficulty is equivalence of products. A combination of low probability and very high consequence may yield the same number as a combination of high probability and moderate consequence, even though the required decisions may be different.
An organization may therefore define each cell’s class directly or establish precedence rules. In some contexts, any intolerable consequence may require escalation regardless of probability. The objective is not to defend a specific calculation, but to build a prioritization rule coherent with project objectives and the nature of the risks.
How to build a risk matrix step by step
A technically consistent sequence begins with governance and ends with a verifiable decision:
- Define objectives and the assessment horizon. Determine which objectives are at stake and the period over which risk will be analyzed.
- Define probability and consequence criteria. Document descriptors, limits, and evidence sources before assessing specific cases.
- Identify risk events. Describe cause, event, and consequence; avoid generic entries such as “delay risk.”
- Record existing controls. Exposure depends on the actual state of prevention, detection, and response.
- Estimate probability. Use history, data, observable conditions, and properly documented expert judgment.
- Estimate consequences. Assess relevant dimensions and apply the defined severity rule.
- Position the risk in the matrix. Determine the class according to approved criteria.
- Compare against acceptance criteria. Decide whether exposure can be accepted, needs treatment, or requires deeper analysis.
- Define owner and response. Assign the risk owner, actions, resources, and deadlines.
- Reassess residual risk. Estimate remaining exposure after additional controls.
- Monitor and review. Update the assessment when assumptions, controls, or context change.
The sequence shows why an isolated colored spreadsheet is insufficient. The matrix must be linked to the decision-making process and the history of the risk.
How to describe an Engineering risk correctly
Vague descriptions reduce assessment quality because they make probability and consequence difficult to estimate. “Delay risk,” for example, does not state what may cause the delay or which objective may be affected.
A useful formulation separates cause → event → consequence. Consider this example: because approval of the detailed design by the responsible authority may be delayed, release for manufacturing may occur after the baseline date, shifting supply beyond the implementation window and affecting the contractual energization milestone.
Now there are elements that can be assessed. The team can seek evidence about approval lead time, design maturity, availability of preliminary review, manufacturing lead time, schedule float, and impact on energization.
This structure also improves treatment. Instead of a generic action to “monitor delay,” measures may include bringing submissions forward, creating a preliminary review, establishing interim milestones, reserving manufacturing capacity, or defining an alternative supply strategy.
Interface risks deserve special attention because they often cross disciplines and companies. Interface Management in Engineering Projects shows how responsibilities and boundaries can be made explicit before they become delays or rework.
Technical example of classification in a multidisciplinary project
Consider modernization of a facility with a restricted implementation window. The team uses a previously calibrated 1-to-5 scale and records four risks. The numbers below are illustrative only; a real project must apply its own criteria.
| Risk | Probability | Consequence | Class | Initial decision |
| delay of long-lead equipment | 4 | 5 | Critical | immediate treatment and escalation |
| incompatibility between disciplines | 3 | 4 | High | technical coordination and early design review |
| unavailability of the operating window | 2 | 5 | High | contingency and early negotiation |
| document discrepancy without functional effect | 2 | 2 | Low | workflow correction and monitoring |
The first risk may require a procurement strategy, alternate supplier, early approval of submittals, or schedule allowance. The second may be treated through coordination, interface review, and requirements freeze. The third requires operating governance and an execution alternative. The fourth may remain under monitoring without consuming the same management attention as critical risks.
The value of the matrix lies precisely in differentiating effort, urgency, and decision authority.
Inherent risk, existing controls, and residual risk
A mature assessment does not record only initial criticality. It must also show the effect of controls and the exposure that remains.
Inherent risk represents exposure in a reference scenario defined by the organization before considering certain additional treatments. Residual risk is the exposure remaining after control or treatment measures are considered.
The distinction prevents a common error: treating a risk as “resolved” simply because an action is planned. An action that has not been implemented may still be delayed, fail, or deliver less reduction than expected.
A consistent record can track initial classification, existing controls, proposed treatment, owner, deadline, expected residual exposure, actually observed residual exposure, and evidence of effectiveness.
In Engineering projects, this matters when acceptance of the remaining exposure depends on schedule, budget, technology, or operating constraints.
Treatment: what to do after classification
Classifying the risk does not complete the decision. High and critical risks must be converted into technically executable treatment, with an owner, deadline, resources, effectiveness criterion, and reassessment of residual exposure.
Support critical decisions with Engineering Technical Consulting →
After assessing criticality, the organization selects a treatment option. Depending on the nature of the risk, this may involve avoiding a condition, eliminating a source, modifying probability, reducing consequence, sharing exposure, or retaining the risk through an informed decision.
The response must take Engineering form. An incompatibility risk may require design review. A supplier risk may require an alternate procurement strategy. An undefined requirement may require a formal client decision. An availability risk may require redundancy, additional testing, or a contingency plan.
Treatments also create secondary risks. Replacing a supplier reduces a schedule exposure but may introduce new qualification uncertainty; adding redundancy reduces operational risk but may increase integration complexity. Treatment must therefore be analyzed as a decision, not as a simple checklist item.
Engineering Technical Consulting is applicable when the decision requires independent assessment, comparison of alternatives, or definition of a technically defensible response before committing resources.
Risk owner, action owner, and decision authority levels
Every significant risk needs a risk owner responsible for monitoring exposure and ensuring that the response progresses. This does not mean the same person will execute every action.
The person responsible for a specific action may be another professional or company. A project manager may own the risk of equipment delay, while the action to issue the specification early belongs to Engineering, negotiation with the manufacturer belongs to Procurement, and approval belongs to the client.
This distinction reduces “ownerless” risks and prevents a team from considering the matter closed merely because a task was assigned.
Governance must also define who may accept each risk level. Low exposures may be managed within the discipline; high risks may require a project manager decision; critical situations may require a technical committee, sponsor, executive management, or the client.
Risk matrix, risk register, and action plan are not the same thing
The matrix is a representation for classification and prioritization. The risk register maintains the attributes and history of each exposure. The response plan describes the actions selected to modify or manage the risk.
| Element | Main function | Typical information |
| Risk matrix | compare criticality | probability, consequence, and class |
| Risk register | maintain traceability | cause, event, consequence, owner, status, history |
| Response plan | control treatment execution | action, responsible party, deadline, resource, and evidence |
A useful register may contain identifier, category, cause, event, consequence, existing controls, probability, impact, criticality, owner, strategy, actions, deadlines, status, residual risk, and review triggers.
The matrix should therefore not be a disconnected image. Project, Program, and Portfolio Governance is a natural path when control needs to be integrated with milestones, decisions, indicators, and PMO responsibilities.
Risk matrix in Technical Due Diligence
In Due Diligence, the matrix can convert a large volume of evidence into intervention priorities. Inspections, documents, interviews, asset records, and tests generate findings; risk assessment clarifies which consequences these findings may produce.
The technical concern is to preserve traceability. It is not enough to label a condition “high.” The report must indicate which evidence supports the finding, which system or asset is affected, which consequence is plausible, which criterion led to the classification, and which treatment is recommended.
The content on Technical Due Diligence Report: evidence, risk matrix, and action plan details this connection among diagnosis, evidence, criticality, and prioritization.
Risk matrix in procurement and contracting
Engineering risks are not limited to technical design. Procurement, manufacturing, logistics, contracts, and commercial interfaces can directly affect schedule, cost, and performance.
A procurement assessment may consider sole-source supply, long-lead equipment, manufacturing capacity, imports, qualification, obsolescence, component availability, manufacturer documentation, FAT, logistics, storage, technical support, and warranty.
Within a contract, the matrix may reveal exposures linked to poorly allocated responsibilities, vague acceptance criteria, client dependencies, scope boundaries, change conditions, warranties, payment milestones, and communication mechanisms.
The objective is not to turn the matrix into legal interpretation of the contract, but to make it an interface among engineering, procurement, management, and legal. Contracts, Scope, and Deliverables Management makes it possible to connect these exposures to the control of obligations, changes, and deliveries.
Risk matrix in design, construction, and commissioning
The nature of risks changes across the project life cycle. During concept development, uncertainty around requirements, technical alternatives, and assumptions predominates. In basic and detailed design, interfaces, incompatibilities, and sizing criteria emerge. During implementation, productivity, logistics, field conditions, safety, changes, and quality become prominent. During commissioning, readiness, integration, test evidence, documentation, and acceptance criteria gain relevance.
For this reason, an initial matrix should not be copied unchanged through project completion. The same risk category may change in probability and consequence as the project matures.
A risk of “late architecture definition” may be critical during concept development and become closed after formal approval. Conversely, a risk of “integration failure” may arise only when supplier interfaces begin to be tested.
Safety, integrity, and reliability require proportional techniques
Not every risk should be governed only through a corporate matrix. Process safety, asset integrity, reliability, and critical systems may require specific techniques and specialized criteria.
IEC 31010 provides guidance on selecting and applying risk assessment techniques in different situations. Depending on the problem, approaches such as FMEA/FMECA, HAZOP, Bow Tie, fault trees, scenarios, or other structured methods may be appropriate.
The matrix may remain useful as a prioritization element, but it does not replace an analysis that needs to understand failure mechanisms, process deviations, barriers, or causal chains. The content on FMEA and FMECA in Maintenance Engineering shows an example of higher-resolution analysis of failure modes and criticality.
When a qualitative matrix is insufficient
The matrix is efficient for screening and communication, but may be insufficient when a decision requires quantifying result distributions, estimating reserves, or measuring the probability of meeting schedule and cost targets.
Signals that assessment needs to advance include risks with large financial exposure, irreversible CAPEX decisions, several correlated risks, a need to size contingency, a need to estimate confidence in schedule milestones, and poor discrimination among important alternatives.
In these cases, scenario analysis, decision trees, probability distributions, and Monte Carlo simulation can add information that a simple “high” class does not provide.
The principle is not to always use the most complex method, but to select the technique in proportion to the decision. Sophistication without adequate data also produces false confidence.
Interactions among risks: why evaluating everything in isolation can fail
Traditional matrices position each risk separately. Real projects, however, contain dependencies. Design delay may shift procurement; procurement delay may reduce the installation window; a smaller window may compress testing; compressed testing increases commissioning and operations exposure.
When each item is evaluated in isolation, the team may underestimate aggregate exposure. The register should allow dependencies, common causes, cascading effects, and systemic risks to be identified.
This is particularly relevant in multidisciplinary projects, where a single interface decision may affect electrical, automation, telecommunications, civil, procurement, and operations at the same time.
How to address opportunities within risk management
ISO 31000 defines risk such that the effect of uncertainty may be positive, negative, or both. In projects, risk management therefore does not need to be limited to threats.
An opportunity may be availability of a technology that reduces CAPEX, the possibility of bringing a purchase forward, an additional operating window, or equipment standardization that reduces inventory and maintenance.
The matrix can be adapted to assess opportunities, but threats and opportunities should not be mixed on a scale designed only for “severity.” Criteria need to reflect the type of effect and the intended decision.
How to keep the matrix alive throughout the project
Risk is dynamic. The probability of a supply delay increases if drawings are not approved and decreases when manufacturing progresses and FAT is completed. The impact of an interface grows as the schedule consumes its float. A risk initially rated moderate may become critical after a scope change.
Review may occur on a defined cadence and also through triggers. Requirement change, supplier replacement, baseline revision, new nonconformity, approval delay, regulatory change, failed test, or changed assumption are examples of events that justify reassessment.
Frequency should be proportional to project dynamics. Reviewing a stable portfolio every week may create bureaucracy; reviewing a fast-moving implementation project every quarter may be insufficient. The objective is to keep the assessment aligned with actual exposure.
Useful indicators for monitoring the risk portfolio
Monitoring should not be reduced to the total number of items. A portfolio with fifty low risks may require less executive attention than another with three critical risks and no effective response.
Useful indicators may include the evolution of high and critical risks, number of overdue treatments, average time without update, distribution by category, residual exposure above the acceptance criterion, and risks without a defined owner.
It may also be useful to track trend: rising, stable, or falling. This makes it possible to distinguish a critical item that is being reduced from one whose exposure continues to increase.
Most common mistakes when using a risk matrix
The matrix loses value when it becomes a bureaucratic exercise. Common mistakes include:
- copying a generic matrix without calibrating criteria for the project;
- assigning numbers without evidence or justification;
- confusing future risk with an issue that has already occurred;
- recording only “delay risk,” without cause and consequence;
- using color as a substitute for decision;
- treating the probability × impact product as an exact quantitative measure;
- ignoring existing controls and their effectiveness;
- not distinguishing initial and residual exposure;
- not assigning an owner, action, and deadline;
- keeping the matrix frozen after the initial workshop;
- assessing risks in isolation without observing interactions;
- allowing intolerable consequences to be diluted by an inappropriate averaging or summing rule.
An independent review often finds more problems with criteria, evidence, and governance than with filling in cells.
Criteria for a technically defensible risk matrix
A matrix is defensible when another qualified professional can understand why a given risk received its classification and which decision resulted from it.
For this purpose, it is useful to verify in sequence:
- criteria were defined and approved before classification;
- levels have clear descriptors;
- information sources are recorded;
- the description separates cause, event, and consequence;
- existing controls were considered;
- the rule for combining probability and consequence is documented;
- special rules exist for intolerable consequences where applicable;
- residual risk is reassessed after treatment;
- owners, deadlines, and authority levels are clear;
- the assessment is reviewed when context changes.
This set turns the matrix into an auditable record of technical decision-making rather than a simple visual presentation.
Final considerations
The risk matrix appears simple but requires consistent criteria to support reliable decisions. Its value is not in choosing between 3 × 3 and 5 × 5 or in the color assigned to each cell. It is in the ability to translate uncertainty into priority, responsibility, treatment, and monitoring.
In Engineering projects, this means connecting classification to requirements, interfaces, schedule, costs, suppliers, technical decisions, contracts, safety, quality, commissioning, and operations. The matrix needs to function as part of the risk management process, not as an isolated document.
When criteria are calibrated, evidence is traceable, risks have owners, and residual exposure is reassessed, the tool supports decisions much more consistently. And when a decision requires greater resolution, it performs another important function: indicating which exposures should proceed to specialized qualitative methods or deeper quantitative analyses.
Risk that is not updated quickly stops representing project reality. Governance needs to connect scope changes, suppliers, milestones, requirements, tests, and decisions to reassessment of exposure and the response plan.
Technical references
[1] BRAZILIAN ASSOCIATION OF TECHNICAL STANDARDS. ABNT NBR ISO 31000: Risk management — Guidelines. Rio de Janeiro: ABNT, 2018. Official international reference. Available at: https://www.iso.org/standard/65694.html
[2] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 31010:2019 — Risk management — Risk assessment techniques. Geneva: IEC, 2019. Available at: https://webstore.iec.ch/en/publication/59809
[3] PROJECT MANAGEMENT INSTITUTE. Risk Management in Portfolios, Programs, and Projects: A Practice Guide. Newtown Square: PMI, 2024. Available at: https://www.pmi.org/standards/risk-management-in-portfolios
Frequently asked questions
It is an assessment and prioritization technique that combines probability or likelihood and consequence criteria to classify exposures and guide treatment, monitoring, or acceptance decisions.
No. ISO 31000 establishes principles, a framework, and a process for risk management, but assessment criteria and techniques must be adapted to context. A 5 × 5 matrix is a methodological choice, not a universal requirement.
Multiplication is a possible semiquantitative convention, but it should not automatically be interpreted as an exact quantitative measure. The combination rule and decision bands must be defined in advance and be coherent with the scales used.
Inherent risk represents exposure in a reference scenario before additional treatments considered by the organization. Residual risk is the exposure remaining after controls and treatments and must continue to be documented, monitored, and reviewed.
When a decision requires quantifying schedule or cost uncertainty, assessing correlated risks, sizing contingencies, or comparing high-impact alternatives, quantitative techniques or specialized methods may be required.
Each relevant risk should have a risk owner responsible for monitoring exposure, ensuring responses progress, and escalating decisions when needed. Execution of specific actions may be assigned to other responsible parties.
No. The matrix represents classification and prioritization. The risk register maintains cause, event, consequence, controls, owner, responses, deadlines, status, residual risk, and review history.
Frequency depends on project dynamics. In addition to a defined cadence, changes in scope, supplier, baseline, requirement, operating condition, test result, or another relevant assumption should trigger review.
Complementary technical materials
Related solutions
- Project, Program, and Portfolio Governance
- Contracts, Scope, and Deliverables Management
- Requirements, Evidence, and Acceptance Criteria Management
Related services
- Engineering Risk Management
- Technical Planning for Engineering Contracting
- Engineering Technical Consulting
Core content on the topic
- Technical Due Diligence Report: evidence, risk matrix, and action plan
- FMEA and FMECA in Maintenance Engineering
- Interface Management in Engineering Projects
Related technical content
- Requirements Management in Engineering
- Project Management: Complete Guide for Engineering, Governance, and Control
- Engineering Management: Processes, Governance, Projects, and Performance
- Owner’s Engineering: Executive Framework for Contracting, Governance, and Acceptance
- Digital Technical Governance for Engineering Companies
