# 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.