Factor I

Govern Sensitive Activities

Principle

Governance should be attached to activities that create risk.

Identify every activity whose incorrect execution could create unacceptable business, legal, financial, security or safety risk, and make those activities explicit within your governance model.

Problem

Every organisation performs activities that carry business, legal, regulatory or security consequences. Approving a payment, releasing software, accessing customer data, granting privileged access, executing a trade or deploying an AI model all create obligations that extend beyond the technical systems involved.

Modern regulation increasingly reflects this reality. Frameworks such as GDPR, DORA, the EU AI Act, financial services regulations and sector-specific security standards are rarely concerned with individual databases, cloud services or APIs. Instead, they regulate activities: how decisions are made, who is accountable, what evidence is retained, and whether appropriate controls were applied.

Effective governance therefore begins by identifying the activities that create risk. Staff and technology are both employed to perform those activities; governance exists to ensure they are performed safely, consistently and with appropriate accountability.

Characteristics

Business impact

Not every operation requires governance. Focus on activities whose failure could materially affect customers, regulators, finances or organisational reputation.

Examples include approving payments, releasing software, modifying production infrastructure or granting privileged access.

Human and automated work

Modern systems increasingly delegate decisions to software, workflows and AI agents. A sensitive activity could comprise of work done by humans, rules engines, machinery, a data processing pipeline or a large language model.

Positive examples

Approving financial transactions

The movement of money creates financial, legal and regulatory obligations. Every payment approval should therefore be subject to policy, authorisation and audit.

Deploying software to production

A production deployment can introduce outages, vulnerabilities or regulatory breaches. Governance ensures changes are reviewed, authorised and supported by appropriate evidence before release.

Granting privileged access

Administrative access gives users the ability to change systems, access sensitive information and bypass normal controls. Such permissions should always be governed and attributable to an accountable owner.

Negative examples

Rendering a user interface

Displaying a web page or mobile screen is a routine implementation detail. While it should be tested for quality, it rarely creates governance obligations in its own right.

Compressing or caching data

Performance optimisations such as compression, caching or image resizing improve efficiency but generally have no direct business or regulatory significance.

Formatting logs or reports

Changing the presentation of information may affect usability, but it does not usually alter business outcomes or introduce material regulatory risk. Governance should focus on the decisions being reported, not how they are displayed.

Anti-patterns

Governing infrastructure instead of outcomes

Security teams often know every server they operate but cannot answer which business activities those servers actually support. That produces excellent infrastructure governance but poor business governance.

Treating everything as sensitive

Attempting to govern every API call, workflow and background process creates overwhelming complexity. Governance should be proportional to risk—concentrate effort where failures have meaningful consequences.

Hidden decision making

Business decisions embedded inside application code, AI prompts or workflow engines often escape governance entirely because nobody recognises them as decision points. If an activity creates risk, it should be visible as something that can be governed.

Assuming humans are the only decision makers

Modern enterprises increasingly rely on automated and AI systems to approve transactions, generate recommendations and initiate actions. If governance only considers human decisions, an increasingly large proportion of organisational risk remains invisible.

Diagram

Where should governance begin?

Attach it to the sensitive steps in a business process—not only to the systems underneath. ★ marks sensitive activities where policy, ownership and evidence attach.

Discussion

Applying this principle does not require building new governance tooling first. It requires changing where governance begins.

1. Catalogue activities, not technical assets, as the starting inventory.
2. Identify which activities would create unacceptable risk if performed incorrectly, without authorisation or without evidence.
3. Give each sensitive activity a clear business owner accountable for its behaviour.
4. Use these activities as the foundation for the following governance factors.

Related factors

This factor sets the scope of Ten Factor Governance.

Everything else hangs off the activities you choose to govern:

• Build a Governance Twin — how those activities are represented as persistent, machine-readable governance objects
• Governance is Version Controlled — once identified, policies and controls for activities should be executable definitions, not documentation alone
• Evidence by Default — sensitive activities need ongoing evidence they are operating correctly, not only periodic audits
• Context In, Decisions Out — policies should govern how activities are performed at runtime, whether the actor is a human, application or AI agent
• Governance Has Owners — every sensitive activity needs an accountable human

References

• Gemara — activity-centred GRC model with a dedicated sensitive-activity layer
• Cedar — principal, action, resource and context as the decision shape
• Open Policy Agent — evaluate structured activity requests before state changes
• XACML — classic request/response evaluation for actions on resources