Technology and Security · Topic 1 of 7
Technology Principles, Roadmaps and Enterprise Architecture
CRISC technology basics: technology principles, cloud models and shared responsibility, technical debt, roadmaps, and enterprise architecture.
- 5 min
- Technology principles make decisions consistent; check they are used, not just written.
- Shared responsibility: the customer always keeps accountability for its data and access.
- Technical debt and legacy systems raise risk over time and belong in the register.
What it is
Technology principles are the agreed rules that guide how an organization chooses, builds and runs technology, such as "reuse before buy, buy before build" or "all customer data stays in approved regions". They make technology decisions consistent and easier to govern.
Enterprise architecture (EA) describes how the business, its data, applications and technology fit together, now and in the future. A technology roadmap is the time-based plan for getting from the current architecture to the target one.
How it works
Common technology principles
| Principle | Risk benefit |
|---|---|
| Alignment with business strategy | Investment supports objectives, not technology for its own sake |
| Standardization | Fewer platforms to secure, patch and support |
| Interoperability | Systems exchange data reliably |
| Scalability and availability | Capacity grows with demand without outages |
| Security and privacy by design | Risk is addressed before build, when it is cheapest |
| Reuse | Proven components reduce new risk |
| Supportability | Technology stays within vendor support |
The practitioner checks that principles exist, are approved, and are actually used in decisions. Exceptions to principles should follow the normal exception process.
Infrastructure and cloud basics
| Model | Customer manages | Provider manages |
|---|---|---|
| IaaS | Operating systems, applications, data, access | Physical infrastructure, virtualization |
| PaaS | Applications, data, access | Platform, runtime, infrastructure |
| SaaS | Data, user access, configuration | Application and everything beneath it |
This split is the shared responsibility model. Whatever the model, the customer remains accountable for its data and for who can access it. Misunderstanding the split is a frequent cause of cloud incidents, such as storage left open to the internet.
Deployment models include public, private, hybrid and multi-cloud. Each changes where data sits, who operates controls and how concentrated the dependency on one provider becomes.
Technical debt and legacy
Technical debt is the future cost of shortcuts taken today: unsupported versions, quick fixes, missing documentation. Legacy systems may no longer receive security patches and often depend on scarce skills. Both increase risk over time and should appear in the risk register and on the roadmap.
Enterprise architecture
EA usually covers four layers: business architecture (capabilities and processes), data architecture, application architecture and technology architecture.
| Framework | What it offers |
|---|---|
| TOGAF (The Open Group) | The Architecture Development Method (ADM), a cycle for developing and governing architecture |
| Zachman Framework | A matrix for classifying architecture descriptions by perspective and question (what, how, where, who, when, why) |
EA helps risk management by showing dependencies, single points of failure, duplicated systems and data flows. An architecture review board checks that new solutions follow principles and standards before they are approved.
Technology roadmaps
A roadmap sequences initiatives over time: replacing legacy platforms, adopting new services, retiring old ones. Good roadmaps are tied to strategy, funded, owned, and reviewed as the business and technology change.
For the practitioner, a roadmap shows when risk will change. A system scheduled for retirement in three years may justify accepting some risk now; one with no replacement plan needs treatment. Roadmaps also show where new technology will introduce risks that need assessment in advance.
A worked example
An insurer's roadmap plans to move its policy administration system to a SaaS platform within two years. The current on-premises system runs on an operating system that leaves vendor support next year.
The practitioner records the end of support risk and recommends compensating controls (network isolation and extra monitoring) until migration. For the SaaS move, the practitioner points out that under the shared responsibility model, the insurer will still own data classification, user access and configuration. These are added as requirements for the architecture review board before vendor selection.
How the exam asks about this
- "What is the PRIMARY benefit of enterprise architecture for risk management?" It shows how business processes, data, applications and technology depend on each other, revealing concentration and gaps.
- "In a SaaS arrangement, who is responsible for managing user access to the organization's data?" The customer organization.
- "A key system is not on the technology roadmap and is approaching end of support. What should the practitioner do FIRST?" Assess and report the risk to the system's business owner.
What to remember for the exam
- Technology principles make decisions consistent; check they are used, not just written.
- Shared responsibility: the customer always keeps accountability for its data and access.
- Technical debt and legacy systems raise risk over time and belong in the register.
- EA layers: business, data, application, technology; TOGAF uses the ADM.
- Roadmaps show when risk will change and where new risks will arrive.
Moving to the cloud transfers operation of some controls, not accountability. If an option suggests the provider is responsible for the customer's data access decisions, it is wrong.
Common mistakes
Treating EA as an IT drawing exercise. EA starts from business capabilities and strategy.
Ignoring end of support dates. Unsupported systems stop receiving security fixes.
Assuming SaaS needs no customer controls. Configuration, access and data remain the customer's job.
Check yourself
What are the four common layers of enterprise architecture?
Business, data, application and technology architecture.
What is technical debt, and why is it a risk?
The future cost of shortcuts such as unsupported versions or quick fixes; it grows over time and makes systems harder to secure and change.
How does a technology roadmap help the risk practitioner?
It shows when systems will be replaced or retired and when new technologies will arrive, which affects treatment decisions and future risk assessments.
Topic 1 of 7 in Technology and Security
Test yourself on Technology and Security
The full ISACA CRISC question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISACA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.