Certified: The ISACA AAIA Audio Course

In this episode, we connect requirements to the real world they have to live in, because a requirement that looks great on paper can still fail if it does not fit the organization’s Enterprise Architecture (E A). For beginners, enterprise architecture can sound like a fancy phrase for diagrams and committees, but the core idea is simple: an organization has an existing environment of systems, data, people, and processes, and any new A I system must fit into that environment safely and predictably. Fit means the system can be integrated, operated, secured, monitored, and governed using the organization’s established practices and capabilities. If it does not fit, the organization may create exceptions, workarounds, and shadow processes that weaken controls and create audit risk. Task 7 focuses on requirements, and this episode shows how evaluating requirements includes evaluating whether they are realistic within the architecture that must support them. This is not about being a systems engineer, it is about asking whether the organization can actually deliver what it promises and control what it deploys. When you understand architecture fit, you can spot requirements that are missing key assumptions about data, interfaces, roles, and operational support.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Start by defining enterprise architecture in plain language: it is the organized view of how technology and business processes work together in an organization. It includes the major applications and services, how they communicate, where data lives, how identity and access are managed, how changes are deployed, and how systems are monitored. It also includes business architecture elements such as workflows, responsibilities, and decision points, because systems exist to support work. When you evaluate A I requirements for architecture fit, you are asking whether the requirements align with these realities. For example, if a requirement assumes real-time data access but the organization’s data is updated in nightly batches, the requirement may be unrealistic or may require significant architectural change. If a requirement assumes a model can be monitored continuously but the organization lacks mature monitoring processes, the requirement may need added governance and tooling plans. Architecture fit evaluation is therefore a reality check that protects the business and protects stakeholders. It helps ensure A I does not become a bolt-on experiment that bypasses controls and creates hidden risk.

A useful way to approach architecture fit is to treat it as a set of alignment questions across five areas: data, integration, identity, operations, and governance. Data alignment asks whether the required inputs exist, are accessible, are trustworthy, and can be used appropriately under privacy and policy constraints. Integration alignment asks whether the A I system can connect to upstream and downstream systems in a controlled way, and whether interfaces and dependencies are understood. Identity alignment asks whether access can be controlled using existing identity and authorization practices, including role-based access and audit logging. Operations alignment asks whether the system can be deployed, maintained, monitored, and supported using the organization’s operational capabilities, including incident response and change management. Governance alignment asks whether ownership, approvals, and oversight fit existing governance structures, or whether the system would create unmanaged exceptions. You do not have to memorize these categories, but thinking in these areas keeps you from focusing only on technical integration while missing the human and process realities. Enterprise architecture fit is not only about where the model runs, it is about whether the organization can govern the system end to end.

Data fit is often the first place A I requirements break, because A I systems depend heavily on data and organizations frequently overestimate the quality and availability of their data. A requirement might say the model must use complete customer history, but the organization might store customer data across multiple systems with inconsistent identifiers. A requirement might say the model must use real-time transaction data, but the organization might only have near-real-time access through delayed feeds. A requirement might assume certain attributes are available, but those attributes might be optional fields that are often missing. For audit thinking, the key is that data fit affects not only model performance but also governance risk, because poor data can create unfair outcomes and misleading decisions. An auditor evaluating fit would ask where each required data element comes from, how it is validated, who owns it, and what access controls apply. If requirements do not specify data lineage, quality expectations, and access constraints, they may not be auditable and may not be realistic. Data fit also includes retention and privacy, because the organization must be able to justify data use and protect sensitive information throughout the lifecycle.

Integration fit is the next major area, because even a well-designed model can fail if it is placed into an environment where its inputs and outputs cannot be handled safely. A requirement might assume the model can call external services, but the organization may restrict outbound connections for security reasons. A requirement might assume the model will integrate with a customer support platform, but the platform may not support the necessary interfaces or may require complex customization. Integration also creates dependency chains, meaning the A I system depends on upstream systems being available and correct, and downstream systems depend on A I outputs being timely and reliable. From an audit perspective, dependencies are risk multipliers because they create more points of failure and more places where change can break behavior. Evaluating requirements for integration fit means asking how the system will be connected, what happens when connections fail, and what the fallback behavior is. It also means asking whether the organization can monitor those connections and detect issues early. If requirements ignore integration and dependency management, they may be incomplete and could lead to audit findings later when failures occur.

Identity and access fit is a crucial part of architecture fit because A I systems often touch sensitive data and can influence high-impact decisions. A requirement might say only authorized staff can view model outputs, but if the organization lacks strong identity management practices, that requirement may not be enforceable. Another requirement might say only a small team can update the model, but if access controls are weak, unauthorized changes could occur and remain undetected. Auditors care because access control is one of the most basic forms of risk management, and it is also a key part of accountability. Fit questions include whether the A I system can use the organization’s existing authentication methods, whether it supports role-based access, and whether it produces logs that tie actions to individual identities. Another fit question is whether access reviews can be performed regularly and whether the organization can quickly revoke access when roles change. If requirements are written without considering identity capabilities, they may sound strong but be impossible to implement in the current environment. Architecture fit evaluation therefore pushes requirements toward enforceable control statements rather than aspirational ones.

Operations fit is often where A I projects become fragile, because operations is the day-to-day reality of keeping systems running and safe. A requirement might say the model must be updated monthly, but if the organization’s deployment processes are slow or inconsistent, updates might be delayed or deployed unsafely. A requirement might say the model must be monitored for drift, but if the organization does not have clear monitoring ownership or incident response processes for model issues, monitoring alerts may be ignored. Operations fit includes questions about change management, version control, rollback capability, and incident handling. It also includes support questions, such as who responds when the system fails at 2 a.m., what service levels are expected, and how business continuity is handled if the model becomes unavailable. For auditors, operations fit is where governance meets reality, because it reveals whether the organization can sustain oversight after the excitement of deployment. A model that is accurate but poorly operated can cause more harm than a simpler model that is well controlled. Requirements should therefore be checked for operational realism, including whether the organization has the capability and capacity to meet them.

Governance fit brings together the human side of architecture, because governance determines whether requirements remain meaningful over time. A requirement might state that changes require approval, but if the organization has no clear approval body or if the approval process is routinely bypassed, the requirement is not a real control. Another requirement might state that fairness testing occurs regularly, but if no role is accountable for reviewing results and acting on them, testing becomes performative rather than protective. Governance fit evaluation asks whether the organization’s existing governance structures can own and oversee the A I system, or whether the system will create a governance gap. It also asks whether risk acceptance decisions are made at the right level, because high-impact A I decisions should not be left to teams without authority to accept consequences. Another governance fit question is whether the system’s use aligns with policies, such as data usage policy, ethics guidelines, and security standards. If requirements conflict with policy, the project will either fail or quietly create exceptions, and both outcomes are audit-relevant. Evaluating fit therefore includes checking whether requirements align with the organization’s governance culture and decision-making pathways.

Let’s ground this with a beginner-friendly example. Imagine a company wants an A I system to automatically approve expense reports to save time. The business goal sounds simple, and the requirement might say the model approves low-risk expenses and flags high-risk ones. Architecture fit questions quickly appear. Data fit asks whether expense data is clean and consistent, whether categories are standardized, and whether receipts are stored in a usable form. Integration fit asks whether the model can connect to the expense platform and whether approvals can be recorded reliably. Identity fit asks whether the model’s actions can be tied to accountable roles and whether only authorized staff can override decisions. Operations fit asks who monitors false approvals, how drift is detected as spending patterns change, and what happens when the model misbehaves. Governance fit asks who owns the risk of improper approvals, what thresholds trigger review, and how audit trails are maintained for investigations. This example shows that architecture fit is not about technical perfection, it is about whether requirements are grounded in what the organization can actually support safely.

A common misconception is that enterprise architecture fit is a technical detail that can be solved later, after the model works. In reality, architecture fit determines whether the system can be controlled, and uncontrolled systems become audit problems. Another misconception is that fit means the A I project must perfectly match existing systems, when sometimes fit can be achieved by adjusting the architecture thoughtfully. The audit point is not to block change, but to ensure change is planned, documented, and governed. Another misconception is that if a vendor offers an A I solution, fit is guaranteed because the vendor has experience. Vendors can help, but the organization still must integrate the solution into its own identity, data governance, monitoring, and approval processes. Fit is always local to the organization’s environment and policies. The exam may test this by offering answers that assume a vendor claim is sufficient. A more audit-aligned answer usually asks how the solution will integrate with existing controls and how governance will be enforced.

When you evaluate requirements for architecture fit, you are also looking for missing requirements that should exist but are not stated. If requirements mention performance but not monitoring, that is a gap because monitoring is necessary to sustain performance and detect drift. If requirements mention data access but not data quality validation, that is a gap because bad data can undermine outcomes. If requirements mention automation but not human override and escalation, that is a gap because automation needs accountability. If requirements mention rapid deployment but not change control and rollback, that is a gap because speed without control increases risk. These gaps often become audit findings later, and Task 7 expects you to recognize them earlier, at the requirements stage. In other words, architecture fit evaluation is partly about checking alignment and partly about checking completeness. Beginners can do this by asking whether each requirement implies supporting processes and controls. If supporting controls are missing, the requirement may be unrealistic or dangerous.

As we close, remember that enterprise architecture fit is simply the question of whether requirements align with the organization’s data reality, integration reality, identity reality, operational reality, and governance reality. Fit protects the organization from building an A I system that cannot be controlled or sustained. It also protects stakeholders by ensuring that constraints like privacy and fairness are enforceable rather than aspirational. For exam purposes, when you see questions about requirements and fit, the best answer often emphasizes verifying integration with existing controls, ensuring clear ownership and monitoring, and identifying gaps that would prevent safe operation. In the next episode, we will focus on spotting hidden assumptions in A I requirements before they become audit findings, because hidden assumptions are one of the most common reasons fit fails. For now, practice translating any A I requirement into a fit check by asking whether data, integration, identity, operations, and governance can support it without creating exceptions.