generated from coulomb/repo-seed
2182 lines
44 KiB
Markdown
2182 lines
44 KiB
Markdown
# InfoTechCanon Governance Model
|
|
|
|
**Short Name:** `ITC-GOV`
|
|
**Document Status:** Seed Standard Release Candidate 1
|
|
**Version:** RC1-seed
|
|
**Date:** 2026-05-22
|
|
**Repository Context:** `info-tech-canon`
|
|
**Document Type:** InfoTechCanon Domain Standard
|
|
**Intended Audience:** Governance designers, enterprise architects, service owners, platform owners, risk managers, compliance reviewers, security architects, quality managers, auditors, product owners, DevSecOps teams, organization designers, knowledge-system builders, standards authors, and agentic tooling.
|
|
|
|
---
|
|
|
|
# 1. Purpose
|
|
|
|
The **InfoTechCanon Governance Model** defines a canonical seed model for representing governance across information-processing systems, organizations, services, platforms, software delivery, security, data, risk, compliance, and operational control.
|
|
|
|
It provides the canonical vocabulary for:
|
|
|
|
- policies,
|
|
- principles,
|
|
- rules,
|
|
- decisions,
|
|
- decision rights,
|
|
- obligations,
|
|
- requirements,
|
|
- controls,
|
|
- control objectives,
|
|
- risks,
|
|
- issues,
|
|
- exceptions,
|
|
- waivers,
|
|
- evidence,
|
|
- assurance,
|
|
- audits,
|
|
- reviews,
|
|
- approvals,
|
|
- governance processes,
|
|
- and governance cycles.
|
|
|
|
This standard is intended to become the third foundational seed standard of InfoTechCanon, following:
|
|
|
|
```text
|
|
InfoTechCanonLandscapeModel
|
|
InfoTechCanonOrganizationModel
|
|
InfoTechCanonGovernanceModel
|
|
```
|
|
|
|
Together these define the first core triad:
|
|
|
|
```text
|
|
Landscape = what exists and how it relates.
|
|
Organization = who can act, belong, own, operate, and be responsible.
|
|
Governance = how action is directed, constrained, justified, reviewed, and evidenced.
|
|
```
|
|
|
|
---
|
|
|
|
# 2. Position in InfoTechCanon
|
|
|
|
The Governance Model is a **domain standard** within InfoTechCanon.
|
|
|
|
It should become the canonical owner of governance concepts that are currently only referenced by the Landscape Model and Organization Model.
|
|
|
|
```text
|
|
InfoTechCanon
|
|
├── InfoTechCanonCore
|
|
├── InfoTechCanonLandscapeModel
|
|
├── InfoTechCanonOrganizationModel
|
|
├── InfoTechCanonGovernanceModel <-- this standard
|
|
├── InfoTechCanonTaskModel
|
|
├── InfoTechCanonTaggingStandard
|
|
├── InfoTechCanonAccessControlModel
|
|
├── InfoTechCanonSecurityModel
|
|
├── InfoTechCanonDataModel
|
|
├── InfoTechCanonDevSecOpsModel
|
|
├── InfoTechCanonPatternLanguage
|
|
└── Application Profiles
|
|
```
|
|
|
|
---
|
|
|
|
# 3. Boundary with Adjacent Standards
|
|
|
|
## 3.1 Boundary with Organization
|
|
|
|
The Organization Model owns:
|
|
|
|
```text
|
|
Actor
|
|
Person
|
|
Agent
|
|
Team
|
|
Organization
|
|
OrganizationalUnit
|
|
Role
|
|
Position
|
|
Membership
|
|
Assignment
|
|
Responsibility
|
|
Authority
|
|
Accountability
|
|
Ownership
|
|
Stewardship
|
|
ReportingLine
|
|
```
|
|
|
|
The Governance Model owns:
|
|
|
|
```text
|
|
Policy
|
|
Principle
|
|
Rule
|
|
Decision
|
|
DecisionRight
|
|
Requirement
|
|
Obligation
|
|
ControlObjective
|
|
Control
|
|
Risk
|
|
Issue
|
|
Exception
|
|
Waiver
|
|
Evidence
|
|
Assurance
|
|
Audit
|
|
Review
|
|
Approval
|
|
GovernanceProcess
|
|
GovernanceCycle
|
|
```
|
|
|
|
Boundary rule:
|
|
|
|
```text
|
|
Organization defines who can act and carry responsibility or authority.
|
|
Governance defines the rules, decisions, controls, obligations, risk structures,
|
|
and evidence systems that direct, constrain, justify, and review action.
|
|
```
|
|
|
|
## 3.2 Boundary with Landscape
|
|
|
|
The Landscape Model owns:
|
|
|
|
```text
|
|
Service
|
|
SoftwareSystem
|
|
RuntimeResource
|
|
NetworkEntity
|
|
DataStore
|
|
Artifact
|
|
DeploymentRecord
|
|
Endpoint
|
|
ObservabilitySignal
|
|
LandscapeRelationship
|
|
```
|
|
|
|
The Governance Model governs these entities but does not own their technical definitions.
|
|
|
|
Example:
|
|
|
|
```text
|
|
Policy governs ApplicationService
|
|
Control applies_to RuntimeWorkload
|
|
Risk affects BusinessService
|
|
Evidence supports LandscapeClaim
|
|
Exception waives Control
|
|
```
|
|
|
|
## 3.3 Boundary with Security
|
|
|
|
The Security Model should own detailed security domain concepts such as:
|
|
|
|
```text
|
|
Threat
|
|
Vulnerability
|
|
AttackPath
|
|
SecurityFinding
|
|
SecurityControlImplementation
|
|
Credential
|
|
Secret
|
|
SecurityEvent
|
|
```
|
|
|
|
The Governance Model owns generic governance concepts such as:
|
|
|
|
```text
|
|
Risk
|
|
Control
|
|
ControlObjective
|
|
Policy
|
|
Exception
|
|
Evidence
|
|
Assurance
|
|
ComplianceRequirement
|
|
```
|
|
|
|
Security-specific governance should be modeled as a profile or specialization of generic governance.
|
|
|
|
## 3.4 Boundary with Access Control
|
|
|
|
Access Control should own:
|
|
|
|
```text
|
|
Permission
|
|
Entitlement
|
|
Credential
|
|
AuthorizationDecision
|
|
AccessPolicyImplementation
|
|
Privilege
|
|
```
|
|
|
|
Governance owns:
|
|
|
|
```text
|
|
AccessPolicy as a policy
|
|
AccessControlObjective as a control objective
|
|
AccessReview as a governance review
|
|
AccessException as an exception
|
|
```
|
|
|
|
---
|
|
|
|
# 4. Research Basis and External Alignment
|
|
|
|
This seed standard draws on multiple bodies of governance knowledge.
|
|
|
|
## 4.1 General Organizational Governance
|
|
|
|
General governance standards such as ISO 37000 emphasize that governance applies to organizations of different types, sizes, structures, and purposes, and that governing bodies or groups guide organizations to fulfill their purpose responsibly.
|
|
|
|
## 4.2 Governance of IT
|
|
|
|
ISO/IEC 38500 and IT governance practice emphasize a governance cycle often summarized as:
|
|
|
|
```text
|
|
Evaluate
|
|
Direct
|
|
Monitor
|
|
```
|
|
|
|
This cycle is highly useful as a canonical governance pattern.
|
|
|
|
## 4.3 COBIT
|
|
|
|
COBIT provides a mature body of knowledge for enterprise governance of information and technology. Its distinction between governance objectives and management objectives, including governance focused on Evaluate, Direct, and Monitor, is important for keeping governance distinct from operational management.
|
|
|
|
## 4.4 COSO Internal Control
|
|
|
|
COSO internal-control thinking contributes the idea that controls exist in an integrated control system with components such as control environment, risk assessment, control activities, information and communication, and monitoring.
|
|
|
|
## 4.5 ISO 31000 Risk Management
|
|
|
|
ISO 31000 provides a general, organization-neutral approach to risk management through principles, a framework, and a process. It reinforces the need to distinguish risk identification, analysis, evaluation, treatment, monitoring, and communication.
|
|
|
|
## 4.6 NIST Cybersecurity Framework 2.0
|
|
|
|
NIST CSF 2.0 introduced `Govern` as one of its top-level functions alongside Identify, Protect, Detect, Respond, and Recover. This supports treating governance as an explicit foundation for cybersecurity and risk management rather than an implicit afterthought.
|
|
|
|
## 4.7 ISO 9001 Roles, Responsibilities, and Authorities
|
|
|
|
Quality management practice emphasizes that responsibilities and authorities must be assigned, communicated, and understood. In InfoTechCanon, Organization owns the actor/role structure, while Governance owns the rules and evidence that ensure responsibilities and authorities are directed and reviewed.
|
|
|
|
## 4.8 Audit, Assurance, and Compliance Practice
|
|
|
|
Audit and assurance practice contributes the distinction between requirements, controls, control objectives, evidence, testing, findings, exceptions, remediation, and assurance conclusions.
|
|
|
|
---
|
|
|
|
# 5. Seed Standard Design Stance
|
|
|
|
This standard is a **seed standard**, not a complete theory of governance.
|
|
|
|
It shall:
|
|
|
|
1. define enough canonical concepts for practical system integration,
|
|
2. distinguish governance from management, organization, security, and access control,
|
|
3. support general governance and IT governance,
|
|
4. support policy, control, risk, evidence, decision, and assurance modeling,
|
|
5. support mappings to external frameworks without becoming subordinate to them,
|
|
6. support regulatory alignment without becoming legal advice,
|
|
7. provide pattern anchors for practical governance mechanisms,
|
|
8. provide profiles for implementation contexts,
|
|
9. remain markdown-first and agent-retrievable,
|
|
10. and support future assimilation of standards, frameworks, regulations, and product models.
|
|
|
|
---
|
|
|
|
# 6. Scope
|
|
|
|
## 6.1 In Scope
|
|
|
|
This standard covers canonical representation of:
|
|
|
|
- governance systems,
|
|
- governance scopes,
|
|
- principles,
|
|
- policies,
|
|
- rules,
|
|
- standards,
|
|
- requirements,
|
|
- obligations,
|
|
- decisions,
|
|
- decision rights,
|
|
- approvals,
|
|
- reviews,
|
|
- controls,
|
|
- control objectives,
|
|
- risks,
|
|
- issues,
|
|
- exceptions,
|
|
- waivers,
|
|
- evidence,
|
|
- audit,
|
|
- assurance,
|
|
- compliance requirements,
|
|
- governance processes,
|
|
- governance cycles,
|
|
- governance bodies as references to Organization concepts,
|
|
- control testing,
|
|
- monitoring,
|
|
- and governance mappings.
|
|
|
|
## 6.2 Out of Scope
|
|
|
|
This standard does not fully define:
|
|
|
|
- all organization theory,
|
|
- all IT service management,
|
|
- all risk management methods,
|
|
- all security domain controls,
|
|
- all legal compliance obligations,
|
|
- full audit methodology,
|
|
- full enterprise architecture governance,
|
|
- full quality management systems,
|
|
- full access-control mechanics,
|
|
- or specific regulatory interpretation.
|
|
|
|
Those may be mapped, assimilated, profiled, or handled by adjacent standards.
|
|
|
|
---
|
|
|
|
# 7. Normative Language
|
|
|
|
The following terms are used normatively:
|
|
|
|
- **SHALL** indicates a mandatory rule for conformance.
|
|
- **SHOULD** indicates a recommended practice.
|
|
- **MAY** indicates an optional capability.
|
|
- **MUST NOT** indicates a prohibited practice.
|
|
- **SEED** marks a concept defined provisionally here but open to later refinement.
|
|
- **EXTRACT** marks a concept that may later move to a more specialized standard.
|
|
|
|
---
|
|
|
|
# 8. Core Principles
|
|
|
|
## 8.1 Governance Is Not Management
|
|
|
|
Governance SHALL be distinguished from management.
|
|
|
|
```text
|
|
Governance evaluates, directs, constrains, authorizes, reviews, and assures.
|
|
Management plans, builds, operates, delivers, improves, and executes.
|
|
```
|
|
|
|
## 8.2 Governance Requires Scope
|
|
|
|
Every policy, control, risk, decision, exception, and obligation SHOULD declare its governance scope.
|
|
|
|
## 8.3 Governance Requires Accountable Actors
|
|
|
|
Governance artifacts SHOULD reference accountable actors through the Organization Model.
|
|
|
|
## 8.4 Policy Is Not Control
|
|
|
|
A policy states intent, rule, or direction.
|
|
A control implements, enforces, verifies, or assures that intent.
|
|
|
|
## 8.5 Requirement Is Not Evidence
|
|
|
|
A requirement states what must be true.
|
|
Evidence supports a claim that something is true.
|
|
|
|
## 8.6 Risk Is Not Finding
|
|
|
|
A risk is uncertainty or exposure relative to objectives.
|
|
A finding is an observed issue, weakness, nonconformity, or result of assessment.
|
|
|
|
## 8.7 Exception Is Not Deletion
|
|
|
|
An exception or waiver does not remove a requirement or control. It records a scoped, justified, time-bound deviation.
|
|
|
|
## 8.8 Governance Should Be Evidence-Carrying
|
|
|
|
Governance claims SHOULD be supported by evidence, source, timestamp, scope, and confidence.
|
|
|
|
## 8.9 External Frameworks Are Mapped, Not Obeyed
|
|
|
|
The Governance Model MAY map to ISO, COBIT, COSO, NIST, ITIL, regulatory, and product models.
|
|
|
|
It MUST NOT subordinate its internal semantics to any single external framework.
|
|
|
|
---
|
|
|
|
# 9. Canonical Seed Metadata
|
|
|
|
Every governance artifact SHOULD support structured metadata.
|
|
|
|
Recommended front matter:
|
|
|
|
```yaml
|
|
---
|
|
id: itc-gov:Policy
|
|
type: concept
|
|
standard: InfoTechCanonGovernanceModel
|
|
standard_version: RC1-seed
|
|
status: candidate
|
|
canonical_owner: InfoTechCanonGovernanceModel
|
|
preferred_label: Policy
|
|
related:
|
|
- itc-gov:Rule
|
|
- itc-gov:Control
|
|
- itc-gov:Requirement
|
|
- itc-org:Authority
|
|
mappings:
|
|
- itc-map:policy-to-cobit-policy-component
|
|
---
|
|
```
|
|
|
|
Recommended artifact statuses:
|
|
|
|
```text
|
|
idea
|
|
draft
|
|
candidate
|
|
release-candidate
|
|
adopted
|
|
stable
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
Recommended concept statuses:
|
|
|
|
```text
|
|
proposed
|
|
experimental
|
|
candidate
|
|
canonical
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
---
|
|
|
|
# 10. Root Governance Taxonomy
|
|
|
|
```text
|
|
GovernanceEntity
|
|
├── DirectionEntity
|
|
│ ├── Principle
|
|
│ ├── Policy
|
|
│ ├── Rule
|
|
│ ├── Standard
|
|
│ ├── Guideline
|
|
│ └── Requirement
|
|
├── DecisionEntity
|
|
│ ├── Decision
|
|
│ ├── DecisionRight
|
|
│ ├── Approval
|
|
│ ├── Review
|
|
│ ├── Escalation
|
|
│ └── GovernanceForum
|
|
├── ControlEntity
|
|
│ ├── ControlObjective
|
|
│ ├── Control
|
|
│ ├── ControlActivity
|
|
│ ├── ControlImplementation
|
|
│ ├── ControlTest
|
|
│ └── ControlResult
|
|
├── RiskEntity
|
|
│ ├── Risk
|
|
│ ├── RiskSource
|
|
│ ├── ThreatReference
|
|
│ ├── Impact
|
|
│ ├── Likelihood
|
|
│ ├── RiskTreatment
|
|
│ └── RiskAcceptance
|
|
├── ComplianceEntity
|
|
│ ├── Obligation
|
|
│ ├── ComplianceRequirement
|
|
│ ├── ControlMapping
|
|
│ ├── ComplianceStatus
|
|
│ └── RegulatoryReference
|
|
├── ExceptionEntity
|
|
│ ├── Exception
|
|
│ ├── Waiver
|
|
│ ├── Deviation
|
|
│ ├── CompensatingControl
|
|
│ └── ExpiryCondition
|
|
├── EvidenceEntity
|
|
│ ├── Evidence
|
|
│ ├── Attestation
|
|
│ ├── Assertion
|
|
│ ├── Finding
|
|
│ ├── Nonconformity
|
|
│ └── Remediation
|
|
├── AssuranceEntity
|
|
│ ├── Audit
|
|
│ ├── Assessment
|
|
│ ├── AssuranceCase
|
|
│ ├── AssuranceConclusion
|
|
│ └── MonitoringActivity
|
|
└── GovernanceSystemEntity
|
|
├── GovernanceSystem
|
|
├── GovernanceScope
|
|
├── GovernanceProcess
|
|
├── GovernanceCycle
|
|
├── GovernanceBodyReference
|
|
└── ManagementInterface
|
|
```
|
|
|
|
---
|
|
|
|
# 11. Core Concepts
|
|
|
|
## 11.1 GovernanceEntity
|
|
|
|
A **GovernanceEntity** is any identifiable concept used to direct, constrain, authorize, review, evidence, or assure action within a defined scope.
|
|
|
|
Recommended attributes:
|
|
|
|
```yaml
|
|
id:
|
|
entity_type:
|
|
canonical_name:
|
|
display_name:
|
|
lifecycle_state:
|
|
governance_scope:
|
|
source_system:
|
|
created_at:
|
|
updated_at:
|
|
```
|
|
|
|
Optional attributes:
|
|
|
|
```yaml
|
|
owner:
|
|
accountable_actor:
|
|
approver:
|
|
review_cycle:
|
|
criticality:
|
|
classification:
|
|
source_confidence:
|
|
valid_from:
|
|
valid_to:
|
|
tags:
|
|
external_references:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.2 GovernanceSystem
|
|
|
|
A **GovernanceSystem** is the organized set of principles, policies, decision structures, controls, risk processes, evidence mechanisms, and assurance activities used to direct and constrain action within a scope.
|
|
|
|
A governance system may govern:
|
|
|
|
```text
|
|
organization
|
|
product
|
|
service
|
|
platform
|
|
software delivery
|
|
security
|
|
data
|
|
architecture
|
|
operations
|
|
compliance domain
|
|
```
|
|
|
|
---
|
|
|
|
## 11.3 GovernanceScope
|
|
|
|
A **GovernanceScope** defines the boundary within which a governance artifact applies.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
whole organization
|
|
business unit
|
|
product
|
|
service
|
|
platform
|
|
environment
|
|
repository
|
|
data domain
|
|
customer tenant
|
|
regulatory domain
|
|
security domain
|
|
```
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
Governance artifacts SHOULD declare their scope.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.4 Principle
|
|
|
|
A **Principle** is a high-level normative statement that guides decisions and design.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Security is built in, not bolted on.
|
|
Production access must be accountable.
|
|
Declared state and observed state must be distinguished.
|
|
External standards are mapped, not obeyed.
|
|
```
|
|
|
|
Principles are more stable and abstract than policies or rules.
|
|
|
|
---
|
|
|
|
## 11.5 Policy
|
|
|
|
A **Policy** is an authoritative statement of intent, direction, constraint, or required behavior within a scope.
|
|
|
|
A policy may be supported by:
|
|
|
|
```text
|
|
rules
|
|
standards
|
|
controls
|
|
procedures
|
|
guidelines
|
|
evidence requirements
|
|
exception processes
|
|
```
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
A policy SHOULD have an accountable owner and a review cycle.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.6 Rule
|
|
|
|
A **Rule** is a more specific directive derived from a policy, standard, regulation, decision, or control objective.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
All production deployments require signed artifacts.
|
|
Privileged scripts must be allowlisted.
|
|
Customer data must not be stored outside approved regions.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.7 Standard
|
|
|
|
A **Standard** is a defined set of required or recommended practices, terms, controls, criteria, or specifications.
|
|
|
|
In InfoTechCanon, a standard may be:
|
|
|
|
```text
|
|
internal InfoTechCanon standard
|
|
external industry standard
|
|
regulatory technical standard
|
|
implementation standard
|
|
quality standard
|
|
security standard
|
|
```
|
|
|
|
---
|
|
|
|
## 11.8 Guideline
|
|
|
|
A **Guideline** is recommended but not strictly mandatory direction.
|
|
|
|
Guidelines may become policies or standards if repeated implementation need or risk justifies stronger normative force.
|
|
|
|
---
|
|
|
|
## 11.9 Requirement
|
|
|
|
A **Requirement** is a statement of a condition, capability, behavior, constraint, or outcome that must be satisfied.
|
|
|
|
Sources of requirements include:
|
|
|
|
```text
|
|
policy
|
|
law
|
|
contract
|
|
standard
|
|
architecture decision
|
|
control objective
|
|
stakeholder need
|
|
risk treatment
|
|
service agreement
|
|
```
|
|
|
|
---
|
|
|
|
## 11.10 Obligation
|
|
|
|
An **Obligation** is a requirement that an actor or organization is bound to satisfy because of law, contract, policy, decision, or accepted responsibility.
|
|
|
|
Obligations SHOULD reference:
|
|
|
|
```text
|
|
source
|
|
bound actor or scope
|
|
required action or condition
|
|
due date or recurrence
|
|
evidence expectation
|
|
consequence of non-fulfillment
|
|
```
|
|
|
|
---
|
|
|
|
## 11.11 Decision
|
|
|
|
A **Decision** is a recorded choice that changes, constrains, authorizes, or interprets action within a scope.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
approve architecture exception
|
|
accept risk
|
|
select platform standard
|
|
authorize production deployment
|
|
deprecate legacy interface
|
|
```
|
|
|
|
---
|
|
|
|
## 11.12 DecisionRight
|
|
|
|
A **DecisionRight** is the authority to make a class of decisions within a defined scope.
|
|
|
|
Decision rights reference Organization concepts such as Actor, Role, Authority, and Accountability.
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
Decision rights SHOULD be scoped, explicit, and reviewable.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.13 Approval
|
|
|
|
An **Approval** is a decision that authorizes a proposed action, artifact, change, exception, release, or state.
|
|
|
|
Approval should not be conflated with evidence. Approval says permitted; evidence says supported.
|
|
|
|
---
|
|
|
|
## 11.14 Review
|
|
|
|
A **Review** is a governance activity that examines an artifact, decision, state, risk, control, or process against criteria.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
architecture review
|
|
access review
|
|
risk review
|
|
control review
|
|
release review
|
|
policy review
|
|
post-incident review
|
|
```
|
|
|
|
---
|
|
|
|
## 11.15 Escalation
|
|
|
|
An **Escalation** is the transfer of a decision, issue, exception, risk, or conflict to a higher or different authority.
|
|
|
|
Escalation SHOULD preserve context, prior decisions, evidence, and unresolved questions.
|
|
|
|
---
|
|
|
|
## 11.16 GovernanceForum
|
|
|
|
A **GovernanceForum** is a recurring or ad hoc structure where governance decisions, reviews, escalations, or interpretations occur.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
architecture board
|
|
security review board
|
|
change advisory board
|
|
risk committee
|
|
data governance council
|
|
product steering group
|
|
```
|
|
|
|
A GovernanceForum references an organizational actor or collective structure but is modeled here as a governance mechanism.
|
|
|
|
---
|
|
|
|
## 11.17 ControlObjective
|
|
|
|
A **ControlObjective** is the intended governance, risk, compliance, quality, or security outcome a control is meant to achieve.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Only authorized actors can change production systems.
|
|
Software artifacts are traceable to source and build process.
|
|
Personal data is processed only within approved scope.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.18 Control
|
|
|
|
A **Control** is a mechanism intended to prevent, detect, correct, direct, or assure behavior relative to a control objective.
|
|
|
|
Control types:
|
|
|
|
```text
|
|
preventive
|
|
detective
|
|
corrective
|
|
directive
|
|
compensating
|
|
automated
|
|
manual
|
|
hybrid
|
|
```
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
A control SHOULD reference at least one control objective.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.19 ControlActivity
|
|
|
|
A **ControlActivity** is an operational activity that implements or performs a control.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
review access list
|
|
verify artifact signature
|
|
run vulnerability scan
|
|
approve change
|
|
reconcile configuration drift
|
|
```
|
|
|
|
---
|
|
|
|
## 11.20 ControlImplementation
|
|
|
|
A **ControlImplementation** is the concrete implementation of a control in a system, process, configuration, workflow, tool, script, or human procedure.
|
|
|
|
Example:
|
|
|
|
```text
|
|
ControlObjective:
|
|
Production deployment requires approval.
|
|
|
|
Control:
|
|
Release approval gate.
|
|
|
|
ControlImplementation:
|
|
GitHub Actions environment protection rule requiring approval by release managers.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.21 ControlTest
|
|
|
|
A **ControlTest** is an assessment activity used to determine whether a control is designed, implemented, and operating effectively.
|
|
|
|
---
|
|
|
|
## 11.22 ControlResult
|
|
|
|
A **ControlResult** is the outcome of a control activity or control test.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
pass
|
|
fail
|
|
not applicable
|
|
inconclusive
|
|
partially effective
|
|
```
|
|
|
|
---
|
|
|
|
## 11.23 Risk
|
|
|
|
A **Risk** is uncertainty or exposure that may affect objectives, outcomes, obligations, services, systems, people, or values.
|
|
|
|
Risk SHOULD include:
|
|
|
|
```yaml
|
|
risk_source:
|
|
affected_scope:
|
|
impact:
|
|
likelihood:
|
|
risk_level:
|
|
treatment:
|
|
owner:
|
|
status:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.24 RiskSource
|
|
|
|
A **RiskSource** is the origin or cause that may give rise to risk.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
threat actor
|
|
supplier dependency
|
|
technical debt
|
|
regulatory change
|
|
single point of failure
|
|
skill concentration
|
|
manual control weakness
|
|
```
|
|
|
|
---
|
|
|
|
## 11.25 Impact
|
|
|
|
An **Impact** is the consequence of risk materialization.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
financial loss
|
|
service outage
|
|
regulatory violation
|
|
data breach
|
|
safety harm
|
|
reputational damage
|
|
delivery delay
|
|
loss of trust
|
|
```
|
|
|
|
---
|
|
|
|
## 11.26 Likelihood
|
|
|
|
**Likelihood** is the assessed chance, frequency, or plausibility of risk occurrence.
|
|
|
|
InfoTechCanon does not mandate a specific likelihood scale. Profiles may define one.
|
|
|
|
---
|
|
|
|
## 11.27 RiskTreatment
|
|
|
|
A **RiskTreatment** is an intended response to risk.
|
|
|
|
Treatment types:
|
|
|
|
```text
|
|
avoid
|
|
reduce
|
|
transfer
|
|
accept
|
|
monitor
|
|
exploit
|
|
```
|
|
|
|
---
|
|
|
|
## 11.28 RiskAcceptance
|
|
|
|
**RiskAcceptance** is a decision to accept a risk within a defined scope, authority, duration, and rationale.
|
|
|
|
Risk acceptance SHOULD be time-bounded and evidence-backed.
|
|
|
|
---
|
|
|
|
## 11.29 ComplianceRequirement
|
|
|
|
A **ComplianceRequirement** is a requirement derived from a law, regulation, standard, contract, policy, certification scheme, or external obligation.
|
|
|
|
---
|
|
|
|
## 11.30 RegulatoryReference
|
|
|
|
A **RegulatoryReference** is a pointer to an external law, regulation, standard, clause, control, article, or official guidance.
|
|
|
|
The Governance Model does not interpret law by default. It records references, mappings, obligations, and evidence expectations.
|
|
|
|
---
|
|
|
|
## 11.31 Exception
|
|
|
|
An **Exception** is an approved deviation from a policy, rule, standard, requirement, or control.
|
|
|
|
An exception SHOULD include:
|
|
|
|
```yaml
|
|
scope:
|
|
justification:
|
|
risk_assessment:
|
|
approver:
|
|
valid_from:
|
|
valid_to:
|
|
compensating_controls:
|
|
review_cycle:
|
|
expiry_condition:
|
|
```
|
|
|
|
---
|
|
|
|
## 11.32 Waiver
|
|
|
|
A **Waiver** is a specific kind of exception that temporarily or conditionally waives enforcement of a requirement or control.
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
Waivers SHOULD expire unless explicitly renewed.
|
|
```
|
|
|
|
---
|
|
|
|
## 11.33 CompensatingControl
|
|
|
|
A **CompensatingControl** is a control used to reduce risk when the primary expected control is absent, weakened, or waived.
|
|
|
|
---
|
|
|
|
## 11.34 Evidence
|
|
|
|
**Evidence** is information used to support a claim, decision, control result, compliance status, risk assessment, audit conclusion, or assurance case.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
log extract
|
|
signed attestation
|
|
ticket
|
|
screenshot
|
|
scan result
|
|
configuration file
|
|
test result
|
|
deployment record
|
|
policy document
|
|
meeting decision
|
|
audit sample
|
|
```
|
|
|
|
---
|
|
|
|
## 11.35 Assertion
|
|
|
|
An **Assertion** is a claim that something is true.
|
|
|
|
Evidence supports assertions.
|
|
|
|
---
|
|
|
|
## 11.36 Attestation
|
|
|
|
An **Attestation** is a signed or otherwise accountable assertion by an actor, system, or process.
|
|
|
|
---
|
|
|
|
## 11.37 Finding
|
|
|
|
A **Finding** is an observed issue, weakness, nonconformity, result, or notable assessment outcome.
|
|
|
|
Finding types:
|
|
|
|
```text
|
|
control_failure
|
|
policy_violation
|
|
risk_observation
|
|
audit_finding
|
|
security_finding
|
|
quality_nonconformity
|
|
process_gap
|
|
data_quality_issue
|
|
```
|
|
|
|
---
|
|
|
|
## 11.38 Nonconformity
|
|
|
|
A **Nonconformity** is a failure to meet a specified requirement, standard, policy, or control expectation.
|
|
|
|
---
|
|
|
|
## 11.39 Remediation
|
|
|
|
**Remediation** is action taken to correct a finding, nonconformity, control weakness, or risk condition.
|
|
|
|
---
|
|
|
|
## 11.40 Audit
|
|
|
|
An **Audit** is a systematic, independent, and documented examination of evidence against criteria.
|
|
|
|
---
|
|
|
|
## 11.41 Assessment
|
|
|
|
An **Assessment** is an evaluation of an artifact, system, process, risk, control, or state against criteria.
|
|
|
|
Audits are a specific kind of assessment with stronger independence and procedural expectations.
|
|
|
|
---
|
|
|
|
## 11.42 AssuranceCase
|
|
|
|
An **AssuranceCase** is a structured argument, supported by evidence, that a claim about governance, risk, compliance, safety, security, or quality is justified.
|
|
|
|
---
|
|
|
|
## 11.43 AssuranceConclusion
|
|
|
|
An **AssuranceConclusion** is the result of an assurance activity.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
effective
|
|
partially effective
|
|
ineffective
|
|
not assessed
|
|
not applicable
|
|
reasonable assurance
|
|
limited assurance
|
|
```
|
|
|
|
---
|
|
|
|
## 11.44 GovernanceProcess
|
|
|
|
A **GovernanceProcess** is a repeatable process for making decisions, reviewing status, managing risk, approving exceptions, monitoring controls, or maintaining policies.
|
|
|
|
Examples:
|
|
|
|
```text
|
|
policy review process
|
|
risk review process
|
|
architecture review process
|
|
exception approval process
|
|
control testing process
|
|
access review process
|
|
release governance process
|
|
```
|
|
|
|
---
|
|
|
|
## 11.45 GovernanceCycle
|
|
|
|
A **GovernanceCycle** is a recurring pattern by which governance is performed.
|
|
|
|
Seed cycle:
|
|
|
|
```text
|
|
Evaluate
|
|
Direct
|
|
Monitor
|
|
Review
|
|
Adapt
|
|
```
|
|
|
|
`Evaluate`, `Direct`, and `Monitor` form the core governance cycle.
|
|
`Review` and `Adapt` are added here to support learning, assimilation, and standard evolution.
|
|
|
|
---
|
|
|
|
# 12. Core Relationship Vocabulary
|
|
|
|
Recommended root relationship types:
|
|
|
|
```text
|
|
governs
|
|
constrains
|
|
requires
|
|
permits
|
|
prohibits
|
|
recommends
|
|
implements
|
|
satisfies
|
|
violates
|
|
derives_from
|
|
interprets
|
|
decides
|
|
approves
|
|
rejects
|
|
waives
|
|
accepts
|
|
escalates_to
|
|
reviewed_by
|
|
owned_by
|
|
accountable_to
|
|
applies_to
|
|
affects
|
|
mitigates
|
|
treats
|
|
monitors
|
|
tests
|
|
evidences
|
|
supports
|
|
challenges
|
|
supersedes
|
|
maps_to
|
|
```
|
|
|
|
Relationship records SHOULD support:
|
|
|
|
```yaml
|
|
id:
|
|
relationship_type:
|
|
source_entity:
|
|
target_entity:
|
|
scope:
|
|
valid_from:
|
|
valid_to:
|
|
source_system:
|
|
confidence:
|
|
evidence:
|
|
rationale:
|
|
```
|
|
|
|
---
|
|
|
|
# 13. Governance State Model
|
|
|
|
Governance artifacts SHOULD use lifecycle and assessment states.
|
|
|
|
## 13.1 Policy States
|
|
|
|
```text
|
|
draft
|
|
under_review
|
|
approved
|
|
active
|
|
suspended
|
|
deprecated
|
|
retired
|
|
superseded
|
|
```
|
|
|
|
## 13.2 Risk States
|
|
|
|
```text
|
|
identified
|
|
analysed
|
|
evaluated
|
|
treatment_planned
|
|
treatment_in_progress
|
|
accepted
|
|
monitored
|
|
realized
|
|
closed
|
|
```
|
|
|
|
## 13.3 Control States
|
|
|
|
```text
|
|
designed
|
|
implemented
|
|
operating
|
|
tested_effective
|
|
tested_ineffective
|
|
not_applicable
|
|
retired
|
|
```
|
|
|
|
## 13.4 Exception States
|
|
|
|
```text
|
|
requested
|
|
under_review
|
|
approved
|
|
rejected
|
|
active
|
|
expired
|
|
renewed
|
|
revoked
|
|
closed
|
|
```
|
|
|
|
## 13.5 Finding States
|
|
|
|
```text
|
|
open
|
|
triaged
|
|
accepted
|
|
remediation_planned
|
|
remediation_in_progress
|
|
remediated
|
|
verified
|
|
closed
|
|
```
|
|
|
|
---
|
|
|
|
# 14. Governance Patterns
|
|
|
|
## 14.1 Pattern: Evaluate-Direct-Monitor
|
|
|
|
**Context:** A governing actor or body must govern a scope without performing all operational work.
|
|
|
|
**Problem:** Governance collapses into either passive reporting or micromanagement.
|
|
|
|
**Solution:** Use a cycle:
|
|
|
|
```text
|
|
Evaluate current and expected conditions.
|
|
Direct through principles, policies, decisions, and priorities.
|
|
Monitor performance, risk, compliance, and outcomes.
|
|
```
|
|
|
|
**Extension for InfoTechCanon:**
|
|
|
|
```text
|
|
Review results and adapt the governance system.
|
|
```
|
|
|
|
---
|
|
|
|
## 14.2 Pattern: Policy-Control-Evidence Chain
|
|
|
|
**Context:** A policy must become practically enforceable and auditable.
|
|
|
|
**Problem:** Policies remain aspirational if they are not linked to controls and evidence.
|
|
|
|
**Solution:**
|
|
|
|
```text
|
|
Policy
|
|
-> Requirement / Rule
|
|
-> ControlObjective
|
|
-> Control
|
|
-> ControlImplementation
|
|
-> ControlActivity / ControlTest
|
|
-> Evidence
|
|
-> AssuranceConclusion
|
|
```
|
|
|
|
---
|
|
|
|
## 14.3 Pattern: Exception with Expiry
|
|
|
|
**Context:** Real systems sometimes cannot comply immediately.
|
|
|
|
**Problem:** Permanent informal exceptions destroy governance integrity.
|
|
|
|
**Solution:** Model exceptions with:
|
|
|
|
```text
|
|
scope
|
|
justification
|
|
risk assessment
|
|
approver
|
|
validity period
|
|
compensating controls
|
|
review date
|
|
expiry condition
|
|
```
|
|
|
|
---
|
|
|
|
## 14.4 Pattern: Risk-to-Treatment Trace
|
|
|
|
**Context:** Risks must lead to action or explicit acceptance.
|
|
|
|
**Problem:** Risk registers become passive lists.
|
|
|
|
**Solution:**
|
|
|
|
```text
|
|
Risk
|
|
-> RiskEvaluation
|
|
-> RiskTreatment
|
|
-> Control / Action / Acceptance
|
|
-> Evidence
|
|
-> Monitoring
|
|
```
|
|
|
|
---
|
|
|
|
## 14.5 Pattern: Decision with Rationale
|
|
|
|
**Context:** Architectural, governance, and operational decisions need traceability.
|
|
|
|
**Problem:** Decisions are forgotten, repeated, or contradicted.
|
|
|
|
**Solution:** Record:
|
|
|
|
```text
|
|
decision
|
|
scope
|
|
context
|
|
options considered
|
|
rationale
|
|
decision authority
|
|
date
|
|
expected consequences
|
|
review trigger
|
|
supersession relation
|
|
```
|
|
|
|
---
|
|
|
|
## 14.6 Pattern: Control Objective Before Control
|
|
|
|
**Context:** Organizations implement controls from checklists.
|
|
|
|
**Problem:** Controls become cargo cults without clear purpose.
|
|
|
|
**Solution:** Define or map the control objective before selecting or implementing controls.
|
|
|
|
---
|
|
|
|
## 14.7 Pattern: Governance Not Management
|
|
|
|
**Context:** Governance and management functions are confused.
|
|
|
|
**Problem:** Governance bodies micromanage operations, or management decisions lack governance direction.
|
|
|
|
**Solution:** Model governance activities separately from management activities, with explicit interfaces.
|
|
|
|
---
|
|
|
|
## 14.8 Pattern: Evidence-Carrying Governance Claim
|
|
|
|
**Context:** A system claims compliance, control effectiveness, or risk reduction.
|
|
|
|
**Problem:** Claims without evidence cannot be trusted or audited.
|
|
|
|
**Solution:** Model the claim separately from its evidence and source.
|
|
|
|
---
|
|
|
|
# 15. Governance Profiles
|
|
|
|
## 15.1 Profile Format
|
|
|
|
A Governance Profile SHALL declare:
|
|
|
|
```yaml
|
|
id:
|
|
profile_name:
|
|
status:
|
|
implements:
|
|
- InfoTechCanonGovernanceModel
|
|
target_context:
|
|
included_concepts:
|
|
required_relationships:
|
|
required_metadata:
|
|
source_of_truth_rules:
|
|
mapping_files:
|
|
validation_rules:
|
|
examples:
|
|
known_deviations:
|
|
```
|
|
|
|
---
|
|
|
|
## 15.2 Seed Profile: Small SaaS Governance Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Provide a minimal governance model for a small SaaS platform moving toward production readiness.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
Policy
|
|
Principle
|
|
Rule
|
|
Decision
|
|
Approval
|
|
Risk
|
|
ControlObjective
|
|
Control
|
|
Exception
|
|
Evidence
|
|
Finding
|
|
Review
|
|
GovernanceProcess
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
Policy governs Service
|
|
Rule derives_from Policy
|
|
Control implements ControlObjective
|
|
Control applies_to RuntimeResource
|
|
Evidence supports ControlResult
|
|
Risk affects Service
|
|
Exception waives Requirement
|
|
Decision approves Exception
|
|
Finding violates Control
|
|
Review monitors Risk
|
|
```
|
|
|
|
---
|
|
|
|
## 15.3 Seed Profile: DevSecOps Governance Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Define governance for secure software delivery without blocking adaptability.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
Policy
|
|
PolicyGate
|
|
Approval
|
|
Decision
|
|
ControlObjective
|
|
ControlImplementation
|
|
ArtifactEvidence
|
|
SBOMEvidence
|
|
Attestation
|
|
Finding
|
|
RiskAcceptance
|
|
Exception
|
|
ReleaseReview
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
Policy governs Pipeline
|
|
PolicyGate implements Control
|
|
PipelineRun generates Evidence
|
|
Artifact attested_by Attestation
|
|
Finding affects Artifact
|
|
RiskAcceptance accepts Risk
|
|
Exception waives PolicyGate
|
|
Approval authorizes Release
|
|
```
|
|
|
|
---
|
|
|
|
## 15.4 Seed Profile: Access Governance Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Connect organization, access control, and governance concepts.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
AccessPolicy
|
|
AccessReview
|
|
DecisionRight
|
|
Approval
|
|
Exception
|
|
ControlObjective
|
|
Control
|
|
Evidence
|
|
Finding
|
|
Remediation
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
AccessPolicy governs Permission
|
|
AccessReview tests AccessControl
|
|
Evidence supports AccessReview
|
|
Finding identifies ExcessAccess
|
|
Approval authorizes AccessException
|
|
Remediation removes Entitlement
|
|
```
|
|
|
|
---
|
|
|
|
## 15.5 Seed Profile: Data Governance Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Define governance concepts for data classification, retention, residency, lineage, and processing obligations.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
DataPolicy
|
|
DataClassificationRule
|
|
RetentionRequirement
|
|
ResidencyRequirement
|
|
ProcessingObligation
|
|
DataControl
|
|
DataException
|
|
Evidence
|
|
DataRisk
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
Policy governs Dataset
|
|
Requirement applies_to DataObject
|
|
Control implements Requirement
|
|
Evidence supports ComplianceStatus
|
|
Exception waives Requirement
|
|
Risk affects Dataset
|
|
```
|
|
|
|
---
|
|
|
|
# 16. Mapping Model for the Governance Standard
|
|
|
|
Mappings relate InfoTechCanon governance concepts to external standards, frameworks, products, and regulations.
|
|
|
|
## 16.1 Mapping Types
|
|
|
|
Recommended mapping types:
|
|
|
|
```text
|
|
exactMatch
|
|
closeMatch
|
|
broadMatch
|
|
narrowMatch
|
|
relatedMatch
|
|
conflictMatch
|
|
gapMatch
|
|
derivedFrom
|
|
regulatoryReference
|
|
```
|
|
|
|
## 16.2 Mapping Record
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
id: itc-map:governance-cycle-to-iso-38500-edm
|
|
source_concept: itc-gov:GovernanceCycle
|
|
target_body: ISO/IEC 38500
|
|
target_version: "2015 or later"
|
|
target_concept: Evaluate-Direct-Monitor
|
|
mapping_type: closeMatch
|
|
scope:
|
|
- IT governance cycle
|
|
not_valid_for:
|
|
- full operational management lifecycle
|
|
rationale: >
|
|
InfoTechCanon uses Evaluate-Direct-Monitor as the core governance cycle
|
|
and adds Review/Adapt for learning and canon evolution.
|
|
confidence: high
|
|
status: candidate
|
|
owner: InfoTechCanonGovernanceModel
|
|
```
|
|
|
|
## 16.3 Seed Mapping Targets
|
|
|
|
The Governance Model SHOULD maintain mappings to:
|
|
|
|
```text
|
|
ISO 37000 governance of organizations
|
|
ISO/IEC 38500 governance of IT
|
|
COBIT 2019
|
|
COSO Internal Control Framework
|
|
ISO 31000 risk management
|
|
NIST CSF 2.0
|
|
ISO 9001 roles, responsibilities, and authorities
|
|
ISO/IEC 27001 / 27002
|
|
ITIL 4 governance and service management
|
|
PMBOK governance and decision structures
|
|
RACI / RASCI models
|
|
ArchiMate motivation and implementation concepts
|
|
ServiceNow GRC / IRM concepts
|
|
Jira / GitHub approval and issue workflow concepts
|
|
```
|
|
|
|
---
|
|
|
|
# 17. Assimilation Hooks
|
|
|
|
The Governance Model SHALL be able to receive new governance bodies of knowledge through the InfoTechCanon assimilation process.
|
|
|
|
## 17.1 Assimilation Triggers
|
|
|
|
Assimilation may be triggered by:
|
|
|
|
```text
|
|
new regulation
|
|
new external governance framework
|
|
new audit framework
|
|
new security standard
|
|
new risk framework
|
|
new quality framework
|
|
new compliance obligation
|
|
new customer contract requirement
|
|
new recurring policy conflict
|
|
new governance failure
|
|
new agentic governance pattern
|
|
```
|
|
|
|
## 17.2 Governance Assimilation Output
|
|
|
|
A governance assimilation SHOULD produce:
|
|
|
|
```text
|
|
source summary
|
|
extracted governance concepts
|
|
concept comparison matrix
|
|
gap list
|
|
conflict list
|
|
mapping file
|
|
candidate new concepts
|
|
candidate relationship changes
|
|
candidate pattern changes
|
|
candidate profile changes
|
|
open questions
|
|
```
|
|
|
|
## 17.3 Recommended First Assimilation Candidates
|
|
|
|
```text
|
|
ISO/IEC 38500
|
|
COBIT 2019
|
|
NIST CSF 2.0
|
|
ISO 31000
|
|
COSO Internal Control
|
|
ISO 37000
|
|
ISO 9001 Clause 5.3
|
|
ISO/IEC 27001 Annex A governance-related controls
|
|
ITIL 4 governance concepts
|
|
```
|
|
|
|
---
|
|
|
|
# 18. Integration with Other InfoTechCanon Standards
|
|
|
|
## 18.1 Organization Model
|
|
|
|
Governance imports organization concepts for:
|
|
|
|
```text
|
|
governance body
|
|
accountable actor
|
|
policy owner
|
|
risk owner
|
|
control owner
|
|
decision authority
|
|
approver
|
|
reviewer
|
|
auditor
|
|
responsible role
|
|
```
|
|
|
|
## 18.2 Landscape Model
|
|
|
|
Governance applies to landscape concepts such as:
|
|
|
|
```text
|
|
BusinessService
|
|
ApplicationService
|
|
TechnicalService
|
|
SoftwareComponent
|
|
Pipeline
|
|
Artifact
|
|
RuntimeResource
|
|
NetworkEndpoint
|
|
Dataset
|
|
Environment
|
|
```
|
|
|
|
## 18.3 Task Model
|
|
|
|
Task imports governance concepts for:
|
|
|
|
```text
|
|
approval
|
|
review
|
|
decision
|
|
escalation
|
|
obligation
|
|
due date
|
|
policy-driven work
|
|
risk-driven work
|
|
exception remediation
|
|
```
|
|
|
|
## 18.4 Tagging Standard
|
|
|
|
Tagging imports governance concepts for:
|
|
|
|
```text
|
|
risk
|
|
control
|
|
policy
|
|
compliance
|
|
exception
|
|
review
|
|
approval
|
|
evidence
|
|
audit
|
|
```
|
|
|
|
## 18.5 Access Control Model
|
|
|
|
Access Control imports governance concepts for:
|
|
|
|
```text
|
|
access policy
|
|
decision rights
|
|
approval
|
|
access review
|
|
exception
|
|
waiver
|
|
control objective
|
|
evidence
|
|
```
|
|
|
|
## 18.6 Security Model
|
|
|
|
Security imports governance concepts for:
|
|
|
|
```text
|
|
security policy
|
|
security control objective
|
|
risk
|
|
exception
|
|
finding
|
|
evidence
|
|
assurance
|
|
compliance requirement
|
|
```
|
|
|
|
---
|
|
|
|
# 19. Canon Interface Card Usage
|
|
|
|
Subsystems that implement or produce governance knowledge SHOULD publish a Canon Interface Card.
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
subsystem: governance-policy-registry
|
|
implements:
|
|
- InfoTechCanonGovernanceModel
|
|
- SmallSaaSGovernanceProfile
|
|
produces:
|
|
- Policy
|
|
- Rule
|
|
- ControlObjective
|
|
- Exception
|
|
- Evidence
|
|
consumes:
|
|
- Team
|
|
- Service
|
|
- RuntimeResource
|
|
relations:
|
|
- Policy governs Service
|
|
- Rule derives_from Policy
|
|
- Control implements ControlObjective
|
|
- Exception waives Rule
|
|
source_of_truth:
|
|
active_policies: governance-policy-registry
|
|
known_deviations:
|
|
- does not perform independent audit
|
|
- does not own organizational roles
|
|
```
|
|
|
|
---
|
|
|
|
# 20. Retrieval Requirements
|
|
|
|
The Governance Model is designed for markdown-based infospaces.
|
|
|
|
## 20.1 Required Retrieval Properties
|
|
|
|
Every major concept SHOULD provide:
|
|
|
|
- stable heading,
|
|
- stable identifier,
|
|
- short definition,
|
|
- longer explanation,
|
|
- examples,
|
|
- distinction notes,
|
|
- relationship examples,
|
|
- mapping hooks,
|
|
- profile references,
|
|
- and common mistakes.
|
|
|
|
## 20.2 Agent Brief
|
|
|
|
A mature Governance Model SHOULD include an `agent-brief.md` file with:
|
|
|
|
```text
|
|
purpose
|
|
scope
|
|
owned concepts
|
|
imported concepts
|
|
core distinctions
|
|
do / do not rules
|
|
relationship patterns
|
|
minimal examples
|
|
common mistakes
|
|
profile list
|
|
mapping list
|
|
```
|
|
|
|
## 20.3 Indexes
|
|
|
|
The governance information space SHOULD provide indexes by:
|
|
|
|
```text
|
|
concept
|
|
relationship
|
|
policy
|
|
control
|
|
risk
|
|
requirement
|
|
exception
|
|
evidence
|
|
profile
|
|
pattern
|
|
mapping target
|
|
status
|
|
source system
|
|
```
|
|
|
|
---
|
|
|
|
# 21. Conformance Levels
|
|
|
|
## 21.1 Reference-Conformant
|
|
|
|
A document or system is reference-conformant if it uses Governance Model terminology consistently but does not implement structured metadata or validation rules.
|
|
|
|
## 21.2 Metadata-Conformant
|
|
|
|
A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.
|
|
|
|
## 21.3 Relationship-Conformant
|
|
|
|
A system is relationship-conformant if it represents policies, controls, risks, exceptions, evidence, reviews, and decisions as explicit relationships.
|
|
|
|
## 21.4 Evidence-Conformant
|
|
|
|
A system is evidence-conformant if governance claims, control results, compliance states, and risk decisions are linked to evidence.
|
|
|
|
## 21.5 Profile-Conformant
|
|
|
|
A system is profile-conformant if it implements a declared Governance Profile and passes its validation rules.
|
|
|
|
## 21.6 Assimilation-Conformant
|
|
|
|
A system or repository is assimilation-conformant if it can accept external governance concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.
|
|
|
|
---
|
|
|
|
# 22. Validation Rules
|
|
|
|
Initial validation rules:
|
|
|
|
```text
|
|
VAL-GOV-001: A Policy SHOULD declare an owner, scope, status, and review cycle.
|
|
|
|
VAL-GOV-002: A Rule SHOULD derive from a Policy, Standard, Requirement, Decision, or external obligation.
|
|
|
|
VAL-GOV-003: A Control SHOULD reference at least one ControlObjective.
|
|
|
|
VAL-GOV-004: A ControlImplementation SHOULD reference the system, process, workflow, or artifact that implements it.
|
|
|
|
VAL-GOV-005: A Risk SHOULD declare affected scope, owner, impact, likelihood or equivalent assessment, and treatment status.
|
|
|
|
VAL-GOV-006: RiskAcceptance SHOULD declare authority, scope, rationale, and validity period.
|
|
|
|
VAL-GOV-007: An Exception SHOULD declare scope, justification, approver, risk assessment, validity period, and expiry condition.
|
|
|
|
VAL-GOV-008: A Waiver SHOULD NOT be permanent unless explicitly justified by a profile.
|
|
|
|
VAL-GOV-009: Evidence SHOULD reference the claim, control result, decision, or requirement it supports.
|
|
|
|
VAL-GOV-010: A Finding SHOULD reference the requirement, control, risk, or assessment that produced it.
|
|
|
|
VAL-GOV-011: Approval MUST NOT be treated as Evidence unless the claim being evidenced is the approval itself.
|
|
|
|
VAL-GOV-012: Governance and management activities SHOULD be distinguished in mature implementations.
|
|
|
|
VAL-GOV-013: Imported external governance concepts SHOULD be represented through mapping records rather than silently reused.
|
|
|
|
VAL-GOV-014: Profiles MUST NOT redefine canonical concepts. They may constrain them.
|
|
|
|
VAL-GOV-015: Governance artifacts SHOULD reference Organization Model actors for ownership, accountability, approval, and review.
|
|
|
|
VAL-GOV-016: Governance artifacts applying to systems SHOULD reference Landscape Model entities where possible.
|
|
```
|
|
|
|
---
|
|
|
|
# 23. Anti-Patterns
|
|
|
|
## 23.1 Policy Without Control
|
|
|
|
A policy exists but no controls, evidence expectations, or review mechanisms make it operational.
|
|
|
|
## 23.2 Control Without Objective
|
|
|
|
A control is implemented because a checklist says so, but nobody can explain which objective it supports.
|
|
|
|
## 23.3 Evidence-Free Compliance
|
|
|
|
Compliance is asserted without evidence.
|
|
|
|
## 23.4 Permanent Exception
|
|
|
|
An exception becomes a hidden permanent policy bypass.
|
|
|
|
## 23.5 Risk Register as Graveyard
|
|
|
|
Risks are recorded but not treated, accepted, monitored, or closed.
|
|
|
|
## 23.6 Approval Theater
|
|
|
|
Approvals are collected without meaningful decision rights, criteria, or accountability.
|
|
|
|
## 23.7 Governance as Micromanagement
|
|
|
|
A governance body directly manages operational details instead of evaluating, directing, monitoring, reviewing, and adapting.
|
|
|
|
## 23.8 Framework Subordination
|
|
|
|
The internal model is bent around a single external framework and loses adaptability.
|
|
|
|
## 23.9 Hidden Decision Rights
|
|
|
|
Decisions are made repeatedly without knowing who has authority to make them.
|
|
|
|
## 23.10 Control Confusion
|
|
|
|
Policy, rule, requirement, control objective, control, implementation, test, and evidence are treated as one thing.
|
|
|
|
---
|
|
|
|
# 24. Initial Repository Placement
|
|
|
|
Recommended repository layout:
|
|
|
|
```text
|
|
info-tech-canon/
|
|
standards/
|
|
governance/
|
|
InfoTechCanonGovernanceModel.md
|
|
agent-brief.md
|
|
concepts/
|
|
relationships/
|
|
patterns/
|
|
profiles/
|
|
mappings/
|
|
assimilation/
|
|
examples/
|
|
validation/
|
|
```
|
|
|
|
Seed files:
|
|
|
|
```text
|
|
standards/governance/InfoTechCanonGovernanceModel.md
|
|
standards/governance/agent-brief.md
|
|
standards/governance/concepts/policy.md
|
|
standards/governance/concepts/control.md
|
|
standards/governance/concepts/risk.md
|
|
standards/governance/concepts/evidence.md
|
|
standards/governance/concepts/exception.md
|
|
standards/governance/concepts/decision.md
|
|
standards/governance/patterns/policy-control-evidence-chain.md
|
|
standards/governance/patterns/exception-with-expiry.md
|
|
standards/governance/patterns/risk-to-treatment-trace.md
|
|
standards/governance/profiles/small-saas-governance-profile.md
|
|
standards/governance/profiles/devsecops-governance-profile.md
|
|
standards/governance/profiles/access-governance-profile.md
|
|
standards/governance/mappings/iso-38500.yaml
|
|
standards/governance/mappings/cobit.yaml
|
|
standards/governance/mappings/nist-csf.yaml
|
|
standards/governance/mappings/iso-31000.yaml
|
|
```
|
|
|
|
---
|
|
|
|
# 25. Roadmap
|
|
|
|
## Phase 1: Seed Stabilization
|
|
|
|
- Establish this standard as `InfoTechCanonGovernanceModel`.
|
|
- Extract governance concepts from the Landscape and Organization models.
|
|
- Add seed concepts, relationship vocabulary, patterns, and profiles.
|
|
- Define validation rules.
|
|
|
|
## Phase 2: Core Alignment
|
|
|
|
- Align with `InfoTechCanonCore` once defined.
|
|
- Move generic mapping, profile, pattern, provenance, and conformance mechanics into Core.
|
|
- Keep only governance-specific applications here.
|
|
|
|
## Phase 3: First Assimilations
|
|
|
|
Recommended first assimilations:
|
|
|
|
```text
|
|
ISO/IEC 38500
|
|
COBIT 2019
|
|
NIST CSF 2.0
|
|
ISO 31000
|
|
COSO Internal Control
|
|
ISO 37000
|
|
ISO 9001 Clause 5.3
|
|
```
|
|
|
|
## Phase 4: Profile Maturation
|
|
|
|
- Create Small SaaS Governance Profile.
|
|
- Create DevSecOps Governance Profile.
|
|
- Create Access Governance Profile.
|
|
- Create Data Governance Profile.
|
|
- Connect profiles to Landscape and Organization models.
|
|
|
|
## Phase 5: Tooling Integration
|
|
|
|
- Generate concept indexes.
|
|
- Generate agent brief.
|
|
- Create machine-readable YAML/JSON exports.
|
|
- Add validation scripts.
|
|
- Use governance model in task, access-control, security, data, DevSecOps, and landscape repositories.
|
|
|
|
---
|
|
|
|
# 26. Summary
|
|
|
|
The InfoTechCanon Governance Model is the seed standard for modeling how action is directed, constrained, justified, reviewed, evidenced, and improved.
|
|
|
|
Its most important commitments are:
|
|
|
|
```text
|
|
Separate governance from management.
|
|
|
|
Separate policy, rule, requirement, control objective, control,
|
|
implementation, test, evidence, risk, finding, exception, and decision.
|
|
|
|
Connect governance to Organization for accountable actors.
|
|
|
|
Connect governance to Landscape for governed systems and services.
|
|
|
|
Use mappings and assimilation to stay connected to external frameworks
|
|
without surrendering internal semantic autonomy.
|
|
|
|
Treat evidence and expiry as first-class mechanisms.
|
|
|
|
Use profiles to make governance practical for concrete implementation contexts.
|
|
```
|
|
|
|
This makes the Governance Model the third foundational seed of InfoTechCanon and a key bridge toward task modeling, tagging, access control, security, data governance, DevSecOps governance, and operational assurance.
|