CISM Security Architecture, Program Resources and Frameworks

Security architecture, program resources and frameworks are the foundations an information security program is built on: the architecture says how controls fit together, the resources (people, process and technology) are what the program runs on, and industry frameworks give it a tested structure of outcomes and controls to adapt. They are the first part of CISM Domain 3, section A (Information Security Program Development), and they relate to three of the 2026 supporting tasks: align the security architecture with the enterprise architecture, update it as the technology landscape changes, and establish and maintain the processes and resources the program needs.

The CISM view is a manager's view. The information security manager does not draw every network diagram or configure every tool. They make sure an architecture exists and stays fit for the business, that the program has the right mix of skills, defined processes and technology, and that frameworks are applied with judgement rather than copied wholesale.

Where this lesson stops: choosing a strategy, aligning with enterprise architecture frameworks such as SABSA, TOGAF or Zachman, selecting a governance framework such as COBIT, and sourcing decisions such as outsourcing are part of Domain 1 (see the lesson on information security strategy). Writing policies and standards, classifying assets, designing individual controls and building metrics are the next part of Domain 3, covered in the lesson on policies, asset classification, control design and metrics.

An information security architecture is the enterprise blueprint that shows how security controls, shared security services and security zones relate to each other, so that every project builds on the same structure instead of inventing its own. It translates the strategy and the enterprise architecture into security building blocks: an identity service every application uses, a standard way to encrypt data, defined zones and the rules for traffic between them, and logging every system feeds.

The architecture sits at a specific level, and it is easy to confuse with the artefacts around it:

The cost of having no architecture shows up as divergence. When each project designs security alone, the organization ends up with, say, a different encryption and key-management approach in every application, logs in incompatible formats, and controls that cannot be managed or monitored together. Divergence is a structural problem, so the lasting fix is structural: an architecture that defines shared services (one key-management service, one logging pipeline) and an expectation that new projects reuse them. Consolidating today's variants helps only if the shared design is then what every future project starts from.

Alignment with the enterprise architecture means the security architecture uses the same business capabilities, data domains and technology roadmap as the rest of IT, so security is designed into planned change instead of added afterwards.

An architecture that teams routinely bypass is failing its purpose. When teams work around it, the first step is diagnosis: talk to the teams and find which patterns are out of date and which delivery needs (cloud services, automation, faster release cycles) the architecture does not cover. Only once the reasons are known can the manager decide what to revise and what to keep enforcing, because an architecture that no longer fits the way the organization builds systems loses support however firmly it is enforced.

Reference architectures and patterns are the approved default designs that projects reuse; a design review checks a new solution against them before it is built, and a justified deviation goes through the exception process rather than being forced into the pattern or waved through.

Review at design time. Conformance to the architecture is cheapest to achieve before build starts, when a design that ignores a shared service can still change. The check that works is a structured review of the solution's actual design against the reference patterns and shared services, done by people who know the architecture, before development is committed. Later activities each answer a different question: testing finds exploitable weaknesses in what was built, and functional acceptance confirms the business got what it asked for; neither tells you whether the design follows the architecture.

Patterns are a default, not an absolute. When a project shows a legitimate requirement the pattern cannot meet (for example, a laboratory instrument vendor that does not support the standard endpoint agent), the proposed alternative is risk-assessed and routed through the documented exception process, where the accountable business owner accepts any residual risk on the record, often with compensating controls and an expiry or review date. The business owns the risk decision, but only after the risk has been assessed and presented.

Recurring exceptions are a signal about the pattern. One exception is a case-by-case decision. When many projects receive exceptions to the same pattern for the same reason (say, the remote-access pattern was written before staff worked from personal tablets), the pattern no longer fits the technology the business actually uses. Each new exception produces another slightly different design, so the manager updates the pattern to cover the new need, giving everyone one approved design, and then retires the exceptions it makes unnecessary.

Defense in depth is the design principle of layering several independent controls so that when one fails, another still protects the asset. Layers span the network, host, application, data and people. It is distinct from principles that describe how a single control behaves:

A single control in front of sensitive data is an architectural weakness, not just a patching problem. If an engineering design repository is protected only by network access rules, any flaw or misconfiguration in that one layer exposes the data. The architectural answer is to add independent controls at other layers, such as application-level authorization and encryption of the stored files, so that the asset stays protected while any single layer is being fixed.

Layers must fail independently. Two controls that work the same way tend to miss the same attacks, so they add little. Two signature-based malware scanners, for example, both miss a brand-new sample that neither vendor has a signature for, while application allowlisting blocks it because it fails in a different way (it stops anything not approved, known or not). A high success rate in one layer is therefore not a reason to remove a layer of a different kind: the remaining attacks are exactly the ones the strong layer misses.

Security zones group systems by the classification and criticality of the information they handle and by their exposure, so the controls at each zone boundary match the risk inside it and systems of different trust levels never share a zone. Typical zones:

• Screened zone (often called a DMZ) for systems that outside parties must reach, such as a supplier portal. The sensitive back end it depends on (for example an order-management system) stays in an internal zone, and only the specific connection the portal needs is allowed between them, which limits what an attacker who compromises the portal can reach.
• Operational technology (OT) zones for control systems, such as a utility's pumping-station controllers or a building's management system, that often cannot run security agents or be patched frequently. They stay separate from the corporate network, and any data exchange passes through a controlled conduit, typically an intermediate zone where data is brokered, so there is no direct path between corporate systems and the control systems. This is the zones-and-conduits model of ISA/IEC 62443: group assets with similar security requirements into zones and control every communication path (conduit) between them.

How data classification itself is carried out is covered in the lesson on policies, asset classification, control design and metrics.

Zero trust is an architecture that grants no implicit trust based on network location or asset ownership: every access request is decided by policy using the identity of the requester, the state of the device and the context of the request. NIST SP 800-207 describes it as moving defenses from static network perimeters to users, assets and resources, with authentication and authorization performed before each session to a resource.

In the NIST model a policy engine makes the access decision, a policy administrator sets up or tears down the session, and a policy enforcement point sits in front of the resource and enforces the decision. Inputs include identity and its authentication strength, device posture (managed, patched, free of detected malware), the resource's sensitivity, and behaviour and threat signals.

What zero trust removes:

• Trust because a request comes from the corporate network or an assigned segment. Segmentation limits movement, but segment membership is still location-based trust.
• Trust carried forward from one sign-in. A check made once and then relied on for the rest of the session is implicit trust for everything that follows.
• Broad access once "inside". Strong authentication answers "who is this?", but if a device at a branch office can then reach every server simply because it is on the branch network, the design still trusts by location and lets an attacker move laterally. Zero trust replaces that with a separate access decision for each application or resource; the strength of the authenticator does not change the trust model.

Access is re-evaluated continuously. When a new risk signal arrives during a session (for example, a contractor's device falls out of compliance because disk encryption was switched off, or the account suddenly signs in from a second country), the inputs behind the original decision have changed, so the decision is taken again and the session can be restricted or ended. The original sign-in proved identity at that moment; it says nothing about the device's or account's state now.

For a manager, adopting zero trust is an architecture change delivered over time: inventory resources and data flows, strengthen identity and device management, then move applications from network-wide access to per-application policy.

The security architecture must be reviewed and updated whenever the technology landscape changes in a way that breaks its assumptions, such as a move to cloud services, an acquisition or joint venture, or remote work from unmanaged devices. The architecture update comes first, because it sets the requirements that tool choices and provider selection must then meet.

• Moving workloads to cloud platforms removes the assumption that applications and data sit behind the organization's own perimeter. The review asks how identity, data protection, logging and access from anywhere must now work; the answers become the requirements that products and providers are measured against.
• Acquisitions and joint ventures often leave two sets of platforms (directories, logging stacks, endpoint tools) running side by side for years. The architecture stays coherent by setting common security standards that both sides must meet (for example authentication strength, account lifecycle and logging content) and defining how the two connect, such as through federation or a shared log pipeline, rather than by waiting for one platform to replace the other.

Cloud service models change who operates a control, not who is accountable for the data. As the model moves from infrastructure (IaaS) to platform (PaaS) to software (SaaS), the provider takes over more layers.

Two practical consequences follow. First, an architecture requirement the customer can no longer perform itself (for example, patching the database engine of a managed PaaS database) still applies; it is met by obtaining assurance that the provider performs it, for example from the provider's independent audit reports, and by recording that reliance. Second, gaps appear where each party assumes the other runs a control, so before signing the manager agrees a responsibility matrix that maps every required control to the provider or the customer, so each party knows exactly what it runs and the customer can plan its own part before go-live. Contract terms and ongoing supplier oversight are covered in the lesson on awareness, external services and program reporting.

Program resources are the people, processes and technologies the information security program needs to carry out its activities, and they only work in combination: technology bought without the people to run it and the processes to direct them fails. This relates to the supporting task of establishing and maintaining the processes and resources the program needs.

Tool without people and process. An endpoint detection and response console that fills up with unexamined detections usually means nobody was assigned to triage them and no process says who handles which detection, how fast, and when to escalate. The fix is on the people and process side; tuning the technology cannot supply an owner.

Tool without prerequisites. A user behaviour analytics tool needs a baseline of normal activity and someone to investigate what it flags. Deployed without those, it produces output nobody acts on, and the more serious consequence is governance: management records the risk as treated, stops looking for a real treatment, and the exposure stays open unseen. Operational problems such as noisy output show up quickly and get fixed; false assurance does not announce itself.

Automate a defined process, not an undefined one. When staff spend much of their time on repetitive steps that are already documented, such as provisioning standard accounts for new joiners, automating those steps scales with volume and frees skilled people for work that needs judgement. Adding headcount for mechanical work grows cost with volume instead. The reverse also holds: automating a process that each person performs differently only makes the inconsistency faster, so define the process first.

Rationalize technology against requirements and the architecture. When regional offices have each bought their own overlapping tools (endpoint agents, for example), the first step is to define the capabilities the program requires (coverage, environments, integration with shared services) and assess each tool against them, so the decision keeps every needed capability and retires the rest. When a consolidation offer does not meet an architecture requirement, treat it as a risk decision: weigh the savings against the risk and cost of the gap, and proceed only if the gap can be closed with a compensating measure or an approved exception. Count only capabilities that exist today.

The people side of the program is managed by comparing the skills each program role requires with the competencies of current staff, and by removing dependencies on single individuals.

Skills gap analysis starts from the work: the program's activities define its roles, each role needs certain skills, and comparing those needs with what staff can actually do shows the gap. The gap then drives training, hiring or external sourcing. The comparison has to be between this program's required skills and these people's demonstrated competence; external benchmarks and administrative records say nothing about which specific skills are missing here.

Key-person risk exists when only one person can run a critical security function, so their illness, leave or resignation stops it. The direct fix is cross-training, which has three parts:

1. Transfer the knowledge to a named backup.
2. Document the procedures.
3. Confirm competence by having the backup perform the tasks unaided while the expert is still available (for example during a rotation or the expert's leave).

For example, if only one engineer can restore the backup platform, the backup is assigned, the runbook written, and then the backup performs a real restore test alone. The third step is what proves the knowledge transferred; written procedures and observation are necessary but do not show that someone else can actually do the work.

Defined processes make security activities consistent. A program process has a named owner, defined inputs and outputs, and documented steps others can follow. Its main benefit is that the activity gives the same quality of result whoever performs it and survives staff changes; it can then be measured, improved and, if repetitive, automated. When people each carry out the same activity their own way, for example each manager approving system changes against different criteria, the fix is to define one process with clear steps and acceptance criteria and train people on it; consistency comes from the defined process, which tools and oversight then support.

Processes must run end to end across functions. A process that hands work from security to another function without an agreed owner on the receiving side stops at the hand-off. For instance, if the security operations team passes confirmed incidents to application teams that have never agreed to fix them, tickets age without action. The first step is to agree the whole process with the receiving function: who acts, within what timeframe for each severity, how exceptions are approved, and how progress is reported. Reporting and automation help once ownership and targets exist.

The NIST Cybersecurity Framework (CSF) 2.0, published in February 2024, organizes cybersecurity outcomes into six Functions (Govern, Identify, Protect, Detect, Respond and Recover) and gives organizations Profiles to set targets and Tiers to describe how rigorous their risk practices are. It is outcome-based and does not prescribe specific controls.

The Functions break down into Categories and Subcategories, which together form the CSF Core. Around the Core sit the components that are easy to confuse:

Using the CSF to plan improvement means comparing a Current Profile with a Target Profile, prioritizing the gaps by risk and business need, and turning them into a funded action plan. The Target Profile reflects the organization's own risk appetite and business priorities, so the CSF does not imply a single right order or a maximum level for everyone. When the question is how rigorous the organization's risk governance is (for example, for a board), Tiers are the component designed to answer it.

Framework control baselines are generic starting points that must be tailored to the organization's risks and business context, and a common control framework maps one tailored control set to every standard and law the organization must meet.

Tailoring adds controls the risk assessment calls for, adjusts others to the environment and scopes out those that do not apply, with a recorded justification, so that the final control set reflects this organization's risk assessment and business context. Three common baselines:

ISO/IEC 27001 does not require every Annex A control. For example, a company that develops no software in-house might decide some secure development controls do not apply; it records each such exclusion and its reason in the Statement of Applicability, which is then examined as part of the certification audit along with the rest of the ISMS.

A common control framework (sometimes called a unified or integrated control framework) is one set of controls, each mapped to all the requirements it satisfies across standards, laws and contracts. Each control is tested once and the result reused, which removes duplicate testing while keeping requirement-specific controls visible. It is needed because each obligation has its own scope and wording: a health-data privacy law covers patient information wherever it is processed, a SOC 2 report covers the systems and trust criteria the company has committed to, and ISO/IEC 27001 covers the scope of the information security management system. The mapping shows, for each requirement, which control meets it, so overlap is tested once and each obligation's distinct requirements still have a named control.

• When a new regulation arrives, the first step is to map its requirements to the existing controls: many will already be met, and the unmapped requirements define the new work. External validation is more useful once the organization knows its own position.
• The mappings must be maintained. When a mapped standard is revised, new or restructured requirements may have no mapped control even though every mapped control still passes testing. For example, ISO/IEC 27001:2022 reorganized Annex A into 93 controls in four themes and added new ones such as threat intelligence, so a framework mapped only to the 2013 edition silently misses them. Review the mappings whenever a source standard changes, and treat requirements with no control alongside passing tests as a sign of stale mappings.