7.4 Principles, Policies, and Frameworks

Quick Answer: Principles, policies and frameworks is a governance-system component, not the Principles exam domain. Principles state values and direction. Policies state formal required and prohibited behavior. Frameworks are structured approaches — including COBIT itself and referenced standards. Procedures explain how to execute. Good practice defines scope, compliance expectations, exceptions, and monitoring. Do not confuse this component with the six system principles.

A component, not the 13% Principles domain

The Foundation blueprint has a Principles domain (about 13%) that tests the six governance-system principles and the three governance-framework principles. This section is not that domain.

This section is one of the seven components inside the 30% Governance System and Components domain. The component’s job is to translate desired behavior into practical day-to-day guidance. Chapter 6’s one-liner still holds. The six system principles are desired behavior at framework altitude. This component is how an enterprise writes that behavior down so people can follow it Monday morning.

Mixing the two is the headline trap. If a stem asks for a component, “provide stakeholder value” is the wrong family. If a stem asks for a system principle, “the acceptable-use policy” is the wrong family. Same English word — principles — two exam objects.

Four related instruments

COBIT groups the vehicles that steer behavior. Learn four terms, even though the component’s official name lists three.

Principles (inside this component) are concise value and direction statements the enterprise wants people to use when no procedure exists. Examples: “We do not accept I&T risk above documented appetite,” “We treat information as an enterprise asset,” “Architecture exceptions are explicit, time-bound, and owned.” These local principles should not contradict the six COBIT system principles, but they are enterprise statements, not the exam’s named list of six.

Policies are formal communications of management intent. They state what is required and what is prohibited. A risk policy requires that material I&T risks be recorded and forbids silent acceptance above appetite. A security policy requires authentication standards and forbids shared production passwords. Policies are mandatory in tone. They are not a process and not a committee.

Frameworks are structured approaches the enterprise adopts so it does not invent governance from a blank page. COBIT 2019 itself is a framework in this sense. So are referenced standards and guidance — ISO/IEC 27001 for information security, NIST CSF, ITIL for service management, TOGAF for architecture, ISO 31000 for risk, and others. Chapter 3 already taught COBIT as an umbrella: it does not replace those frameworks; this component is where the enterprise says which frameworks apply and how they fit.

Procedures are the how-to. They sit under policies. The risk policy says every high risk needs a treatment decision inside ten business days. The procedure says who updates the register, which form to use, and how the risk committee pack is built. Procedures are not principles. They are not frameworks. They are executable steps. They are also not the process component: a procedure is a document that tells people how to execute; a process is the practices-and-activities slot on the objective.

Good practice: make the rules usable

A policy that cannot be followed is decoration, same as a process nobody runs.

Scope states who and what the instrument covers — all I&T, only production, only third parties, only a subsidiary. Ungoverned scope is how two policies contradict each other.

Compliance expectations state what “following this” looks like and what happens if someone does not. COBIT does not require you to invent punishments. It does require the enterprise to say that compliance is expected and how it will be judged.

Exceptions are designed, not whispered. Good policy says who may grant an exception, for how long, with what residual risk, and where it is recorded. The architecture board and risk committee you met in 7.3 often own those exception decisions. An exception path is not weakness; informal workarounds are.

Monitoring closes the loop. Someone checks that the policy is alive: sample access reviews, exception aging, training completion, MEA assurance. Monitoring here is policy monitoring. It complements EDM monitoring and MEA monitoring; it does not replace them.

Review and communicate. A 2014 encryption policy that never mentions cloud or mobile is a framework failure dressed as a document. The information and people components will carry the message; this component supplies the message worth carrying.

Work a small example. The enterprise adopts COBIT plus ISO 31000 as its risk frameworks. It publishes a risk principle (“no silent acceptance above appetite”) and a risk policy that requires every high I&T risk to have an owner, a treatment decision, and a review date. A procedure tells the risk analyst how to update the register before the monthly risk committee. EDM03 and APO12 supply the process. The risk committee and CRO supply the structure. None of those nouns is interchangeable.

How this component works with processes and structures

The three components in this chapter are a triad. Processes say what work happens. Organizational structures say who may decide. Principles, policies and frameworks say what behavior is required while that work and those decisions happen.

EDM03 and APO12 need a risk policy and an adopted risk framework. The risk committee needs operating principles (a structure good practice) and a risk policy (this component). The process activities then execute the policy. If you only write APO12 practices and never adopt a policy, people cannot tell required from optional. If you only write a policy and never name a structure, nobody can grant an exception. If you only name a structure and never adopt a framework, every meeting reinvents the method.

Exam trap: six system principles versus this component

Memorize the collision:

• Six system principles — provide stakeholder value; holistic approach; dynamic governance system; governance distinct from management; tailored to enterprise needs; end-to-end coverage. Exam domain: Principles.
• Three framework principles — based on a conceptual model; open and flexible; aligned to major related standards. Still the Principles domain.
• This component — the enterprise’s principles, policies, frameworks, and procedures that translate desired behavior into guidance. Exam domain: Governance System and Components.

If the item lists the seven components and asks which one translates desired behavior into practical guidance, the answer is principles, policies and frameworks. If the item asks which system principle requires several component types to work together, the answer is holistic approach — that is Chapter 4, not this component.

A second trap is calling COBIT “only a policy.” COBIT is a framework the enterprise may adopt inside this component, and it is also the product family you are studying. A third trap is calling a procedure a process: a procedure is how to execute; a process is the practices-and-activities component for an objective. A fourth is treating a policy as a metric or as a capability level. Keep the instrument names tight and this 30% slice stays clean.