coulomb/info-tech-canon
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
info-tech-canon/seeds/InfoTechCanonGovernanceModel_RC1_seed.md

44 KiB
Executable File
Raw Permalink Blame History

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:

InfoTechCanonLandscapeModel
InfoTechCanonOrganizationModel
InfoTechCanonGovernanceModel

Together these define the first core triad:

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.

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:

Actor
Person
Agent
Team
Organization
OrganizationalUnit
Role
Position
Membership
Assignment
Responsibility
Authority
Accountability
Ownership
Stewardship
ReportingLine

The Governance Model owns:

Policy
Principle
Rule
Decision
DecisionRight
Requirement
Obligation
ControlObjective
Control
Risk
Issue
Exception
Waiver
Evidence
Assurance
Audit
Review
Approval
GovernanceProcess
GovernanceCycle

Boundary rule:

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:

Service
SoftwareSystem
RuntimeResource
NetworkEntity
DataStore
Artifact
DeploymentRecord
Endpoint
ObservabilitySignal
LandscapeRelationship

The Governance Model governs these entities but does not own their technical definitions.

Example:

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:

Threat
Vulnerability
AttackPath
SecurityFinding
SecurityControlImplementation
Credential
Secret
SecurityEvent

The Governance Model owns generic governance concepts such as:

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:

Permission
Entitlement
Credential
AuthorizationDecision
AccessPolicyImplementation
Privilege

Governance owns:

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:

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.

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:

---
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:

idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired

Recommended concept statuses:

proposed
experimental
candidate
canonical
deprecated
retired

10. Root Governance Taxonomy

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:

id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
governance_scope:
source_system:
created_at:
updated_at:

Optional attributes:

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:

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:

whole organization
business unit
product
service
platform
environment
repository
data domain
customer tenant
regulatory domain
security domain

Canonical rule:

Governance artifacts SHOULD declare their scope.

11.4 Principle

A Principle is a high-level normative statement that guides decisions and design.

Examples:

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:

rules
standards
controls
procedures
guidelines
evidence requirements
exception processes

Canonical rule:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

preventive
detective
corrective
directive
compensating
automated
manual
hybrid

Canonical rule:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

draft
under_review
approved
active
suspended
deprecated
retired
superseded

13.2 Risk States

identified
analysed
evaluated
treatment_planned
treatment_in_progress
accepted
monitored
realized
closed

13.3 Control States

designed
implemented
operating
tested_effective
tested_ineffective
not_applicable
retired

13.4 Exception States

requested
under_review
approved
rejected
active
expired
renewed
revoked
closed

13.5 Finding States

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:

Evaluate current and expected conditions.
Direct through principles, policies, decisions, and priorities.
Monitor performance, risk, compliance, and outcomes.

Extension for InfoTechCanon:

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:

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:

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:

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:

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:

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:

Provide a minimal governance model for a small SaaS platform moving toward production readiness.

Included concepts:

Policy
Principle
Rule
Decision
Approval
Risk
ControlObjective
Control
Exception
Evidence
Finding
Review
GovernanceProcess

Required relationships:

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:

Define governance for secure software delivery without blocking adaptability.

Included concepts:

Policy
PolicyGate
Approval
Decision
ControlObjective
ControlImplementation
ArtifactEvidence
SBOMEvidence
Attestation
Finding
RiskAcceptance
Exception
ReleaseReview

Required relationships:

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:

Connect organization, access control, and governance concepts.

Included concepts:

AccessPolicy
AccessReview
DecisionRight
Approval
Exception
ControlObjective
Control
Evidence
Finding
Remediation

Required relationships:

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:

Define governance concepts for data classification, retention, residency, lineage, and processing obligations.

Included concepts:

DataPolicy
DataClassificationRule
RetentionRequirement
ResidencyRequirement
ProcessingObligation
DataControl
DataException
Evidence
DataRisk

Required relationships:

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:

exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference

16.2 Mapping Record

Example:

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:

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:

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:

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

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:

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:

BusinessService
ApplicationService
TechnicalService
SoftwareComponent
Pipeline
Artifact
RuntimeResource
NetworkEndpoint
Dataset
Environment

18.3 Task Model

Task imports governance concepts for:

approval
review
decision
escalation
obligation
due date
policy-driven work
risk-driven work
exception remediation

18.4 Tagging Standard

Tagging imports governance concepts for:

risk
control
policy
compliance
exception
review
approval
evidence
audit

18.5 Access Control Model

Access Control imports governance concepts for:

access policy
decision rights
approval
access review
exception
waiver
control objective
evidence

18.6 Security Model

Security imports governance concepts for:

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:

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:

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:

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:

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:

info-tech-canon/
  standards/
    governance/
      InfoTechCanonGovernanceModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/

Seed files:

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:

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:

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.

Reference in New Issue View Git Blame Copy Permalink