Introduction
Enterprise risk management has traditionally operated in silos. Chief Risk Officers focus on financial risks. Chief Information Officers manage technology risks. Compliance officers address regulatory risks. Business unit leaders manage operational risks. Each function develops frameworks, policies, and controls addressing their specific risk domain. Yet this siloed approach misses critical insights: risks in one domain cascade through organizational systems creating compounding effects, interdependencies between systems create vulnerabilities not visible within individual domains, and organizational design choices create hidden risk exposures that remain unmanaged because no single function views them as responsibility.
Enterprise architecture provides missing lens for integrated risk management. Enterprise architecture maps organizational systems—business processes, data flows, applications, technology infrastructure, organizational structure—and their interdependencies. This comprehensive view reveals how risks propagate across systems, how disruptions in one area cascade through others, where single points of failure create organizational vulnerability, and where competing risk mitigation strategies create conflicts requiring coordinated management.
Organizations increasingly recognize that enterprise risk management requires enterprise-wide perspective. A process redesign might introduce operational risk if new steps don't adequately incorporate controls. Technology infrastructure changes might create security vulnerabilities if data flows are modified without security assessment. Organizational restructuring might concentrate critical knowledge in small groups creating knowledge continuity risks. Data strategy decisions might create privacy risks if data governance isn't coordinated with systems management. Without enterprise architecture lens, these cross-domain risks remain invisible until failures occur.
This article examines how enterprise architecture enables integrated risk management. We begin by developing taxonomy of enterprise risks spanning business, data, application, and technology domains. We then explore how architecture analysis identifies risks through dependency mapping, cascade effect analysis, and scenario simulation. We examine how risks should be governed, monitored, and mitigated through integrated governance structures. Finally, we address how enterprise risk management integrates with regulatory compliance and business continuity planning.
Enterprise Risk Taxonomy
Comprehensive risk management requires systematically categorizing risks so none are overlooked and governance focus aligns with risk significance.
Risk Categories and Classification
Strategic Risks: Risks threatening organizational strategy achievement or competitive positioning. Strategic risks include market risks (competitors outmaneuver organization), technology disruption risks (new technologies make organizational capabilities obsolete), regulatory risks (regulation changes unfavorably), and stakeholder risks (customers or key partners abandon organization).
Operational Risks: Risks threatening day-to-day operational execution. Operational risks include process risks (processes fail or underperform), resource risks (critical resources become unavailable), supplier risks (key suppliers fail to deliver), and quality risks (output quality degrades).
Financial Risks: Risks threatening financial performance and stability. Financial risks include credit risks (counterparties fail to meet obligations), liquidity risks (organization lacks cash when needed), commodity/currency risks (prices move unfavorably), and investment risks (investments underperform expectations).
Technology Risks: Risks threatening technology systems and infrastructure. Technology risks include infrastructure risks (systems fail or become unavailable), cyber security risks (systems are compromised by unauthorized access), technology obsolescence risks (technology becomes outdated), and vendor risks (technology vendors fail or discontinue support).
Compliance Risks: Risks threatening regulatory compliance and legal standing. Compliance risks include regulatory violation risks (organization violates applicable regulations), contractual breach risks (organization fails to meet contractual obligations), litigation risks (organization faces lawsuits), and environmental/social risks (organization causes environmental harm or social damage).
Data Risks: Risks threatening data quality, availability, and privacy. Data risks include data quality risks (data becomes inaccurate or incomplete), data loss risks (data is lost through disaster or deletion), data privacy risks (confidential data is disclosed to unauthorized parties), and data governance risks (data stewardship is inadequate).
Organizational Risks: Risks threatening organizational capability and culture. Organizational risks include capability risks (organization lacks required skills), change management risks (organizational change is resisted or poorly executed), knowledge continuity risks (critical knowledge is lost when people leave), and cultural risks (organizational values erode).
Interdependency Risks: Risks emerging from interconnections between systems and processes. Interdependency risks include cascade risks (failures in one area trigger failures in connected areas), bottleneck risks (concentration of critical functions creates vulnerability), integration risks (integrations between systems fail), and coordination risks (lack of coordination between functions creates gaps).
Risk Magnitude Assessment
Beyond categorizing risks, organizations should assess risk magnitude:
Likelihood: Probability that risk will materialize. Some risks are highly likely (technology obsolescence is virtually guaranteed), while others are low probability (organization-wide power outage is unlikely).
Impact: Magnitude of consequence if risk materializes. Some risks would be minor inconveniences if they occurred. Others would threaten organizational viability.
Velocity: Speed with which risk materializes. Some risks develop gradually over months or years, providing time to respond. Others can materialize rapidly with little warning.
Detectability: Likelihood that risk will be detected before causing harm. Some risks create obvious symptoms if they're developing. Others can be hidden until failure occurs.
Controllability: Degree to which organization can control or influence risk. Some risks are internal (controllable through organizational action). Others are external (influenced but not fully controlled).
Risk prioritization should focus management attention on high-likelihood, high-impact, low-detectability, low-controllability risks—these create greatest organizational exposure.
Risk Identification Through Architecture Analysis
Business Architecture Risk Assessment
Business architecture documents organizational structure, processes, and decision-making. This documentation reveals several risk categories:
Process Risks: Processes might lack adequate controls enabling errors to occur. Processes might be fragile—dependent on specific individuals, equipment, or systems with no backup. Processes might have single points of failure where disruption would halt downstream processes.
For example, a process where critical approvals depend on single individual creates knowledge continuity risk and key-person dependency risk. If that individual departs, becomes ill, or is unavailable, the process halts. Architecture analysis should identify such dependencies and propose mitigations—backup approvers, delegation procedures, cross-training.
Organizational Risks: Organizational structure can concentrate critical functions in small groups or individuals, creating vulnerability. Organizational restructuring can disrupt knowledge transfer and create transition risk. Lack of clear accountability can create gaps where risks slip between functions.
Governance Risks: Governance structures might lack clarity about decision authority or accountability. Governance might be slow, preventing timely risk response. Governance might be so decentralized that consistent policies aren't maintained, creating compliance risk.
Data Architecture Risk Assessment
Data architecture documents what data organization manages, how data is organized and governed, and data quality.
Data Quality Risks: If data quality is poor—incomplete, inaccurate, or outdated—then decisions based on data lead to poor outcomes. For example, customer data that isn't current might result in communications sent to wrong addresses or service interruptions due to billing information being inaccurate.
Data Governance Risks: If data governance is unclear—who owns data, who can access data, how data is maintained—then data quality suffers, data inconsistencies emerge, and regulatory compliance risk increases. Data governance risk is particularly acute for sensitive data (personal information, financial data, health information).
Data Security Risks: Data security architecture should specify who has access to what data, how access is controlled, how data is encrypted, how data is backed up, and how data is securely deleted. Architecture gaps—unencrypted sensitive data, inadequate access controls, no backup procedures—create data security risk.
Data Loss Risks: Without adequate backup and disaster recovery architecture, data could be permanently lost through system failure, corruption, or malicious action. Data loss would disrupt operations and potentially violate legal obligations to maintain records.
Application Architecture Risk Assessment
Application architecture documents what applications organization operates, what functions they provide, and how they integrate.
Application Dependency Risks: Applications that depend on other applications create interdependency risk—if depended-upon application fails, dependent applications also fail. For example, if customer data application fails, all applications depending on customer data also fail. Architecture analysis maps these dependencies identifying single points of failure.
Legacy System Risks: Older applications might be difficult to modify, creating risk if requirements change. Legacy systems might have inadequate security controls or performance characteristics. Legacy systems might be running on unsupported technology, creating risk when technology providers discontinue support.
Integration Risks: Systems that are tightly integrated might create fragility—problems in one system cascade to others. Systems that are inadequately integrated might create data inconsistency or duplication risks. Integrations that are brittle (fail if even small data format changes occur) create operational risk.
Cybersecurity Risks: Applications might have security vulnerabilities enabling unauthorized access. Applications handling sensitive data might lack adequate encryption or access controls. Applications might lack adequate logging enabling investigation of incidents.
Technology Infrastructure Risk Assessment
Technology infrastructure documents computing platforms, networks, storage, and security controls.
Infrastructure Availability Risks: Infrastructure that lacks redundancy creates availability risk. If single server fails, services become unavailable. If network link fails, connectivity is lost. If storage system fails, data becomes inaccessible. Infrastructure assessment identifies single points of failure and assesses whether redundancy is adequate.
Capacity Risks: Infrastructure might lack adequate capacity for organizational needs. If infrastructure can't handle peak demand, services degrade during high-demand periods. Growing demand might exceed infrastructure capacity, requiring expansion that takes time and money to implement.
Security Infrastructure Risks: Inadequate firewalls, intrusion detection, or access controls create security vulnerability. Unpatched systems create vulnerability to known exploits. Inadequate encryption creates risk that confidential data could be compromised.
Disaster Recovery Risks: Infrastructure might lack backup systems or disaster recovery capability. If primary facility is damaged or becomes unavailable, recovery time and data loss depends on backup/recovery capability. Assessment should verify that disaster recovery capability is adequate for organizational tolerance for downtime and data loss.
Vendor/Supplier Risks: Technology infrastructure often depends on external vendors—cloud providers, software vendors, hardware vendors. If vendors fail to deliver, have outages, or discontinue support, organization faces disruption. Vendor assessment should evaluate financial stability, service level agreements, and customer support quality.
Dependency-Based Risk Modeling
Mapping Dependencies
Enterprise architecture's primary value for risk management is making dependencies explicit and visible. Dependencies exist between:
- Processes: Process A depends on output of Process B
- Systems: System A depends on data from System B or functionality provided by System B
- Organizations: Business Unit A depends on resources provided by Business Unit B
- Infrastructure: Application depends on network connectivity, storage, or computing resources
- People: Process depends on skills of specific individuals
Dependency mapping documents these relationships systematically. Modern enterprise architecture tools often include dependency mapping capabilities, though even simple documentation (spreadsheets, diagrams) can be effective.
Analyzing Single Points of Failure
Once dependencies are mapped, analyze where critical dependencies create single points of failure. Single point of failure is anything whose failure would cause cascading failures in dependent systems.
For example:
- Single data center: If only one data center is available, failure makes all applications unavailable
- Single network link: If only one link connects to internet, link failure disconnects organization
- Single database: If database fails, all applications depending on that database fail
- Single person: If key expertise exists with single individual, departure creates disruption
- Single supplier: If single vendor provides critical capability, vendor failure disrupts operations
Single points of failure should be candidates for redundancy, backup capability, or contingency planning.
Cascade Effect Analysis
When single point of failure occurs, what cascade effects result? For example:
- Primary database fails → Applications depending on primary database fail → Business processes supported by those applications fail → Customers affected by failed business processes experience service disruption
Understanding cascade chains enables:
- Prioritizing which single points of failure to address (failures with severe cascade effects warrant higher priority for mitigation)
- Designing backup/recovery strategies appropriately (backup strategy must enable recovery within acceptable timeframe for each dependent system)
- Communication planning (understanding what services are affected helps communicate appropriately with customers)
- Testing plans (testing should verify that cascade scenarios can be recovered from)
Scenario Simulation for Risk Assessment
Beyond static architecture analysis, risk assessment can be enhanced through scenario simulation exploring how risks propagate through organizational systems under different conditions.
Risk Scenario Definition
Risk scenarios describe hypothetical adverse events and their cascade effects. Scenarios should be realistic and plausible—risks that could actually occur given organizational environment and history.
Example risk scenarios:
Cyber Attack Scenario: Attacker gains unauthorized access to customer data system, exfiltrating customer information. What's organizational impact? What systems become unavailable? How long until recovery? What regulatory consequences?
Key Person Departure Scenario: Critical architect or key manager unexpectedly departs. What knowledge is lost? What processes are disrupted? How quickly can replacement be found and ramped up? What service level impact results?
Supplier Failure Scenario: Key supplier discontinues service. What functionality becomes unavailable? How quickly can alternative supplier be engaged? What customer impact results?
Data Corruption Scenario: Data in critical system becomes corrupted. How extensive is data loss? How quickly can corrupted data be restored from backup? What service interruption results?
Capacity Exceedance Scenario: Unexpected surge in demand (viral social media mention, competitor outage driving traffic to organization) causes demand to exceed infrastructure capacity. What systems become overloaded? What service degradation occurs? How quickly can capacity be added?
Simulation Modeling
Scenarios can be modeled using process simulation tools to quantify impacts:
Timeline Impact: How long will it take to detect risk has materialized? How long will recovery take? What is total downtime duration?
Financial Impact: What costs result from service interruption? What recovery costs occur? What customer refunds or penalties result?
Operational Impact: What processes are affected? What customers are impacted? What service level impact results?
Reputational Impact: How would incident affect brand perception? Would customers switch providers? What media coverage would result?
Regulatory Impact: Would incident trigger regulatory notification requirements? What fines or enforcement action would result?
Scenario simulation enables assessing risk impact quantitatively rather than qualitatively, informing prioritization of risk mitigation efforts.
Risk Correlation and Cascade Effects
Correlated Risks
Risks are often not independent—they correlate with other risks. When one risk occurs, probability of other risks increases.
For example:
- If cybersecurity attack occurs, probability that attacks on backup systems also occur increases
- If key technical person departs, probability that other key people depart (due to disruption or reduced opportunity) increases
- If supply chain disruption occurs, probability that financial stress results increases
- If technology fails, probability that manual workaround systems also fail (due to increased workload) increases
Understanding correlations enables:
- Stress testing assumptions about independent risks
- Recognizing that risk mitigation for one risk might create exposure to correlated risks
- Designing mitigation strategies that address root causes of correlated risks
Risk Cascade and Amplification
Risks don't simply occur in isolation. Often, initial risk triggers other risks, which trigger yet others, creating cascade effect.
Example cascade:
- Primary data center experiences power failure
- All systems in data center become unavailable
- Failover systems in secondary data center become active but are overwhelmed by load
- Failover systems become capacity-constrained, causing response time degradation
- Users experience severe service degradation leading to frustration
- Some users give up trying to access systems, creating social media complaints
- Media picks up story, amplifying reputational damage
- Regulatory authority investigates, issuing non-compliance findings
Understanding cascades enables:
- Breaking cascade chains through appropriate controls (if failover systems were adequately sized, cascade wouldn't progress to response time degradation)
- Prioritizing mitigation efforts where they can stop cascades
- Preparing response strategies for anticipated cascades
Integrated Risk Governance
Risk Governance Structure
Enterprise-wide risk management requires governance structure integrating risk management across functions:
Enterprise Risk Management Committee: Executive-level committee chaired by Chief Risk Officer or CFO, with representation from business, technology, compliance, and operations. Committee meets regularly to review enterprise risk landscape, evaluate major risk scenarios, approve risk mitigation strategies, and monitor implementation of mitigations.
Risk Committees by Domain: Domain-specific committees addressing particular risk categories:
- Information Security Committee addressing cyber and data security risks
- Technology Steering Committee addressing technology risks
- Business Continuity Committee addressing operational continuity risks
- Compliance Committee addressing regulatory compliance risks
These domain committees report to Enterprise Risk Committee, ensuring coordination across domains.
Architecture Review Board Integration: Architecture decisions create or mitigate risks. Architecture Review Board should include risk management perspective in technology decisions. Major architectural changes should be evaluated for risk implications before approval.
Business Unit Risk Ownership: Business units should own operational risks and compliance risks in their domains. Risk ownership includes identifying risks in their business unit, implementing controls, and reporting risk status to enterprise risk committee.
Risk Assessment and Monitoring
Enterprise risk management requires systematic risk assessment and ongoing monitoring:
Annual Risk Assessment: At least annually, conduct comprehensive risk assessment updating risk landscape. Assessment should identify new risks emerging from environmental changes, verify that existing risk mitigation strategies are effective, and identify risks increasing or decreasing.
Risk Dashboard: Develop dashboard tracking key risk metrics—risk exposures by category, trends in risk indicators, status of risk mitigation efforts. Dashboard should be available to executive leadership for monitoring and decision-making.
Risk Reporting: Regular (at minimum quarterly) reporting to executive leadership and board on risk status. Reports should highlight risks trending negatively, risks requiring executive attention, and status of risk mitigation efforts.
Leading Indicators: Beyond tracking incidents (lagging indicators), organizations should track leading indicators suggesting risk is increasing:
- System uptime percentages (declining uptime suggests availability risk increasing)
- Security vulnerability assessments (increasing vulnerabilities suggest security risk increasing)
- Customer satisfaction metrics (declining satisfaction suggests operational risk increasing)
- Employee turnover (increasing turnover suggests organizational capability risk increasing)
- Audit findings (increasing findings suggest compliance risk increasing)
Risk Mitigation Strategies
Once risks are identified and assessed, mitigation strategies should be developed.
Mitigation Approaches
Risk Avoidance: Choosing not to engage in activity creating risk. For example, organization might choose not to operate in certain geographic regions due to political instability risk.
Risk Reduction: Implementing controls to reduce likelihood or impact of risk. For example, implementing backup systems reduces impact if primary system fails. Implementing security controls reduces likelihood of cyber attack succeeding.
Risk Transfer: Shifting risk to external parties through insurance, contracts, or outsourcing. For example, organization might purchase cyber liability insurance transferring financial impact of cyber incident.
Risk Acceptance: Consciously accepting risk as inherent to doing business. Risk acceptance should only occur when likelihood or impact is low enough that risk is within organizational risk tolerance.
Risk Response Planning: Developing contingency plans describing how organization will respond if risk materializes. Response planning accelerates response when incident occurs, reducing impact.
Mitigation Implementation Roadmap
Risk mitigation doesn't happen instantly. Organizations should develop roadmaps prioritizing mitigation efforts:
Immediate Actions: High-priority risks with low cost or effort to mitigate should be addressed immediately. For example, implementing backup procedures might be low-cost mitigation for data loss risk.
Near-Term Actions (1-6 months): Moderately important mitigations requiring moderate effort. For example, implementing redundant network links requires infrastructure investment but moderate effort.
Medium-Term Actions (6-18 months): More complex mitigations requiring significant effort or organizational change. For example, technology platform migration might take 12+ months.
Long-Term Actions (18+ months): Transformational mitigations requiring significant investment and organizational change. For example, organizational restructuring to eliminate single points of failure might take years.
Roadmap should be prioritized based on risk exposure—highest exposure risks should be addressed first.
Regulatory Compliance Integration
Regulatory Risk Landscape
Risk management increasingly must address regulatory requirements. Different regulators impose different risk management obligations:
Financial Regulators: Bank regulators, insurance regulators, securities regulators require enterprises to implement risk management frameworks addressing operational risk, compliance risk, and market risk. Regulations typically specify minimum risk management practices.
Data Privacy Regulators: GDPR, CCPA, and similar regulations require enterprises managing personal data to implement privacy risk management addressing data security, data breach notification, and data subject rights.
Industry-Specific Regulators: Healthcare, energy, telecom, and other regulated industries have specific risk management requirements.
General Governance Standards: Sarbanes-Oxley and similar requirements impose obligations on corporate governance and risk management.
Compliance-Risk Integration
Enterprise risk management should integrate compliance risk with other risk categories. Compliance risk exists when organization violates regulatory requirements. Mitigation strategies for compliance risk include:
- Understanding regulatory requirements applicable to organization
- Assessing organizational compliance with requirements
- Implementing controls ensuring ongoing compliance
- Monitoring compliance and investigating violations
- Remediating violations when discovered
Compliance risk management should be integrated with broader enterprise risk management rather than isolated within compliance function.
Business Continuity and Resilience
Business Continuity Planning
Identifying risks is important, but equally important is planning how organization will respond if risks materialize. Business continuity planning documents:
Recovery Time Objectives (RTO): How long can service be unavailable before unacceptable harm occurs? Different services have different RTOs—critical services might have RTO of hours, non-critical services might have RTO of days.
Recovery Point Objectives (RPO): How much data loss is acceptable? Different data has different RPO—critical data might have RPO of minutes (all data recovered since last backup), less critical data might have RPO of days.
Recovery Strategies: How will organization recover if disaster occurs? Strategies might include:
- Backup systems in geographic location independent of primary location
- Manual processes enabling continued service if systems are unavailable
- Vendor relationships enabling rapid repair or replacement
- Supplier agreements ensuring critical supplies can be obtained
Testing and Validation: Recovery plans should be tested regularly—disaster recovery drills verify that recovery procedures work as designed. Testing often reveals issues in plans before actual disasters occur.
Organizational Resilience
Beyond recovery plans, organizations should build resilience—ability to absorb disruption and adapt. Resilience is built through:
- Redundancy: Multiple sources of critical capabilities so loss of one source doesn't disrupt organization
- Flexibility: Processes and systems that can adapt to different conditions
- Learning: Mechanisms for learning from incidents and continuously improving
- Communication: Transparency about risks and incidents building stakeholder trust
- Culture: Organizational culture valuing continuous improvement and adaptation
Advanced Risk Management Approaches
Machine Learning for Risk Detection
Emerging machine learning approaches can enhance risk detection:
Anomaly Detection: Machine learning models can learn normal patterns of system behavior and detect anomalies suggesting problems. For example, anomalous network traffic patterns might indicate cyber attack.
Predictive Risk Models: Machine learning models can predict probability of risks based on observable indicators. For example, models predicting customer churn risk based on behavioral patterns enable proactive retention efforts.
Pattern Recognition: Machine learning can identify patterns in data suggesting emerging risks. For example, pattern recognition in financial data might identify indicators of fraud.
Scenario Stress Testing
Beyond simulating individual risk scenarios, stress testing explores how organization performs under multiple simultaneous adverse events:
- Multiple Failure Scenario: What if primary data center fails AND key manager departs AND major customer leaves simultaneously?
- Prolonged Disruption: What if recovery takes longer than anticipated?
- Coordination Failure: What if communication breaks down between organization and recovery partners?
Stress testing reveals how resilient organization is to multiple simultaneous challenges.
Common Risk Management Challenges
Challenge 1: Siloed Risk Management
Problem: Risk management functions operate independently without integration.
Solution: Establish enterprise risk committee coordinating risk management across functions. Use enterprise architecture as lens for identifying cross-functional risks.
Challenge 2: Risk Invisibility
Problem: Many risks are hidden in organizational complexity and aren't visible through traditional analysis.
Solution: Use architecture analysis to map dependencies and identify risks not visible in siloed view.
Challenge 3: Executive Attention Volatility
Problem: Executive attention to risk management fluctuates based on recent incidents rather than underlying risk exposure.
Solution: Develop regular reporting and monitoring keeping risk management consistent focus.
Challenge 4: Compliance-Risk Disconnect
Problem: Compliance focuses on regulatory requirements while risk management focuses on business impact. The two functions don't coordinate.
Solution: Integrate compliance risk into broader enterprise risk management, recognizing that compliance violations create business risk.
Conclusion
Enterprise architecture enables integrated risk management revealing interconnections and dependencies that traditional siloed approaches miss. By viewing risk through architecture lens—understanding business processes, data flows, applications, and technology infrastructure as integrated system—organizations identify hidden risks emerging from architectural design choices, hidden cascade effects that might not be visible within individual functions, and opportunities for risk mitigation addressing root causes rather than symptoms.
Successful enterprise risk management combines several elements: clear taxonomy of enterprise risks spanning all risk categories; systematic risk identification through architecture analysis; simulation-based scenario analysis enabling quantitative risk assessment; integrated governance structures coordinating risk management across functions; regular monitoring and reporting maintaining consistent focus; and resilience building enabling organizations to absorb disruption and adapt.
Organizations implementing enterprise risk management through architecture-based approaches achieve substantial benefits: reduced probability of major incidents; faster recovery when incidents occur; better-informed decision-making accounting for risk implications; improved regulatory compliance; and greater organizational resilience. In increasingly complex organizational environments where interdependencies create hidden risks, enterprise architecture-based risk management is essential management practice distinguishing organizations that successfully navigate risks from those surprised by them.
References
Arena, M. V., Upadhyay, V., Cummings, M. L., & Delatte, D. (2014). Workforce Skill and Allocation Optimization Problem. Journal of Defense Analytics and Logistics, 8(2), 96-118.
Arora, K., Dey, A., & Pattnaik, P. (2018). Enterprise Architecture Risk Management: A Comprehensive Framework. International Journal of Engineering and Technology, 7(4), 1-8.
Asare, S. K., & Ferrara, E. J. (2014). Audit Evidence and Research. Journal of Accounting Literature, 35(1), 1-28.
Bamford, J., & Ernst, D. (2002). Managing an Alliance Portfolio. McKinsey Quarterly, 3, 29-39.
Barton, D., & Court, D. (2012). Making Advanced Analytics Work for You. Harvard Business Review, 90(10), 78-83.
Beasley, M. S., Branson, B. C., & Pagach, D. P. (2010). The State of Risk Oversight: An Overview of Enterprise Risk Management Practices. COSO.
Beck, M. B., Duen, W., Davis, M., & Fang, J. (2008). System Integrity and Sustainability in Assessing Enterprise Risk. Risk Analysis, 28(5), 1199-1216.
Bertalanffy, L. V. (1968). General System Theory: Foundations, Development, Applications. George Braziller.
Boh, W. F., & Yelland, P. M. (2007). Using Enterprise Architecture Standards in Managing Information Technology. Journal of Management Information Systems, 23(3), 163-207.
Bromiley, P., McShane, M., Nair, A., & Rustambekov, E. (2015). Enterprise Risk Management: Review, Critique, and Research Directions. Long Range Planning, 48(4), 265-276.
Buchanan, B., & Smith, M. (2015). The Use of Analytics to Improve Data Center Operations and Management. Journal of Technology Research, 7(1), 1-13.
Burt, D. N., & Pinkerton, R. L. (1996). Strategic Procurement and Supply Chain Management. Journal of Supply Chain Management, 32(1), 44-51.
COSO. (2004). Enterprise Risk Management – Integrated Framework. Committee of Sponsoring Organizations of the Treadway Commission.
COSO. (2013). Internal Control – Integrated Framework. Committee of Sponsoring Organizations of the Treadway Commission.
COSO. (2017). Enterprise Risk Management – Integrating with Strategy and Performance. Committee of Sponsoring Organizations of the Treadway Commission.
Davies, A., Gann, D., & Douglas, T. (2009). Innovation in Large Complex Projects: The Case of London Heathrow Terminal 5. Project Management Journal, 40(5), 16-31.
Dawood, N. N., & Mallasi, Z. (2006). Construction Workspace Planning: Assignment and Layout of Temporary Facilities Using Mixed-Integer Programming. Journal of Construction Engineering and Management, 132(4), 432-440.
De Cruydt, H., Lievens, F., & Van Keer, E. (2011). Use of Video Conferencing for Recruitment Interviews: Applicant Reactions and Interviewer Ratings. International Journal of Selection and Assessment, 19(4), 389-397.
Dekker, S. W., & Hollnagel, E. (2004). Human Factors and Folk Models. Cognition, Technology & Work, 6(2), 79-86.
DeLone, W. H., & McLean, E. R. (2003). The DeLone and McLean Model of Information Systems Success: A Ten-Year Update. Journal of Management Information Systems, 19(4), 9-30.
Denning, P. J., & Dunham, R. H. (2010). The Innovator's Way: Essential Practices for Successful Innovation. MIT Press.
Deshpande, R., & Farley, J. U. (2004). Organizational Culture, Market Orientation, Innovativeness, and Firm Performance: An International Research Odyssey. International Journal of Research in Marketing, 21(1), 3-22.
Diem, N. H., Huong, N. L., & Thao, N. T. P. (2019). Enterprise Risk Management in Supply Chain: A Systematic Literature Review. International Journal of Supply Chain Management, 8(4), 136-149.
Doroudi, F., Mousavi, S. M., & Hosseini, S. A. (2016). A Framework for Enterprise Risk Management Using Internal Audit Function. International Journal of Academic Research in Accounting, Finance and Management Sciences, 6(3), 45-56.
Eisenhardt, K. M. (1989). Building Theories from Case Study Research. Academy of Management Review, 14(4), 532-550.
Fahey, L., & Christensen, H. K. (1986). Evaluating the Research for Significant Strategic Issues. Strategic Management Journal, 7(4), 323-334.
Felici, M., & Luca, C. (2013). Enterprise Architecture Principles for Security Information Management. IT Professional, 15(4), 36-42.
Fenton, N. E., & Bieman, J. M. (2014). Software Metrics: A Rigorous and Practical Approach (3rd ed.). CRC Press.
Fitzgerald, B., Hartnett, G., & Conboy, K. (2006). Customising Agile Methods to Semicritical Software Systems. European Journal of Information Systems, 15(2), 200-213.
Foorthuis, R., van de Wetering, R., & Brinkkemper, S. (2016). A Theory Building Study of Sourcing Governance in Rapidly Changing Technology Environments. Journal of Strategic Information Systems, 25(2), 81-99.
Fors, M. N., & Qureshi, S. (2006). Enterprise Resource Planning as Virtual Organization: Learning from ERP Implementation in Pakistani Organizations. Journal of Global Information Management, 14(3), 27-42.
Friedberg, H., Remedios, J., & Spinola, M. M. (2015). Risk Factors for Unreliable Software Projects. Journal of Software Engineering Research and Development, 3(1), 1-16.
Gatzlaff, K. M., & McCullough, K. A. (2015). The Impact of Data Breaches on Shareholder Wealth. Risk Management and Insurance Review, 13(2), 231-256.
Goel, R. K., & Saunoris, J. W. (2020). Supply Chain Performance and Economic Growth. Journal of Supply Chain Management, 51(2), 3-15.
Gordon, L. A., Loeb, M. P., & Zhou, L. (2015). The Impact of Information Security Breaches: Has the Cybersecurity Risk Been Growing? Journal of Critical Infrastructure Policy, 10(1), 13-28.
Grant, D., & Nolan, T. (2016). Case Study Methodology and System Dynamics Modelling for Organisational Change in Higher Education. International Journal of Educational Management, 30(1), 44-56.
Hakansson, H., & Snehota, I. (1995). Developing Relationships in Business Networks. Routledge.
Hambrick, D. C., & Mason, P. A. (1984). Upper Echelons: The Organization as a Reflection of Its Top Managers. Academy of Management Review, 9(2), 193-206.
Handfield, R. B., & McCormack, K. P. (2007). Supply Chain Risk Management. CRC Press.
Harmon, P., & Wolf, C. (2012). Business Process Modeling Survey. Business Process Trends.
Hendrick, T. E., & Ellram, L. M. (1997). Supplier Selection Criteria in the Healthcare Industry. International Journal of Purchasing and Materials Management, 33(4), 40-49.
Hillston, J. (2005). A Compositional Approach to Performance Modelling. Cambridge University Press.
Hochstein, A., Tamm, G., & Brenner, W. (2005). Service-Oriented IT Management. Journal of Information Technology Management, 16(1), 29-36.
Hodgkinson, G. P., Whittington, R., Johnson, G., & Schwarz, M. (2006). The Role of Strategy Workshops in Strategy Development Processes. Long Range Planning, 39(6), 629-649.
Holliday, I. (2000). Productivist Welfare Capitalism: Social Insurance and Social Assistance in East Asia. Political Studies, 48(4), 706-723.
Hoogeweegen, M. R., Teunter, L. H., & van Wassenhove, L. N. (2000). A Decision Support Tool for Supply Chain Management. Supply Chain Management, 5(1), 42-50.
Hu, Q., & Luo, X. R. (2015). Examining Multi-Dimensional Trust and Multi-Faceted Risk in Initial Acceptance of Emerging Technologies. European Journal of Information Systems, 15(4), 414-439.
ISO. (2009). Risk Management – Principles and Guidelines (31000:2009). International Organization for Standardization.
ISO. (2018). Risk Management – Guidelines (31000:2018). International Organization for Standardization.
Jain, P., & Tiwari, M. K. (2014). Enterprise Resource Planning: A Competitive Necessity for Indian Industries. Business Process Management Journal, 20(2), 235-258.
Johnson, M. E., & Whang, S. (2002). E-business and Supply Chain Management: An Overview. Production and Operations Management, 11(4), 413-423.
Jurisch, M. C., Ikas, C., Wolf, P., & Krcmar, H. (2013). Key Differences of Private and Public Sector BPM. Business Process Management Journal, 19(2), 276-297.
Kalagnanam, J., & Pardalos, P. M. (2004). Algorithms for Cluster Transportation Problems. Computers & Operations Research, 31(7), 1017-1029.
Kaplan, R. S., & Norton, D. P. (1992). The Balanced Scorecard: Measures That Drive Performance. Harvard Business Review, 70(1), 71-79.
Katz, D., & Kahn, R. L. (1978). The Social Psychology of Organizations (2nd ed.). Wiley.
Kingsman, B. G., & Mercer, A. (1997). Demand Tagging and Forecasting for Demand Management in Make-to-Order Environments. International Journal of Production Research, 35(2), 427-452.