Application & Data Governance Policy
Document Number: ISMS-POL-ADG-01
Classification: L1 — Policy (Domain)
Version: 0.1.3
Effective Date: March 1, 2026
Author: Lucas Shin — Security Director
Approved By: Richard — CISO
Next Review Date: February 2027
Parent Policy: Information Security Policy (ISMS-POL-ISP-01)
1. Purpose
This policy defines the security governance framework for approved applications and data handling within the Cybercraft operational environment.
While Supplier & Third-Party Security Policy (ISMS-POL-STP-01) governs whether a tool may be adopted (supplier evaluation), this policy governs how approved tools are securely operated — including account management, data context isolation, identity governance, and AI data sovereignty.
Scope Distinction:
- P5 (Supplier): "Can this tool be adopted?" — Supplier evaluation, contract review, risk classification
- P3 (This Policy): "How do we securely operate approved tools?" — Account management, data isolation, AI sovereignty
- P2 §7 (BYOD): "How is access granted from BYOD devices?" — Access path and method controls (e.g., via Managed Edge)
P-Numbering Reference: The P1–P9 abbreviations used in this document are defined in the Domain Policy Index at Information Security Policy (ISMS-POL-ISP-01) §5.1.
2. Scope
2.1 Applicable Systems
- All apps registered in the Approved SaaS Register as assessed under Supplier & Third-Party Security Policy (ISMS-POL-STP-01) §3
- Business SaaS, PaaS, and AI services outside of M365
- All external applications that hold or process corporate information assets
2.2 Applicable Users
- All Cybercraft employees and M365 account holders
- Cross-tenant personnel (Techtype, HVT) who use applicable apps
- External collaborators (Level 2/3) accessing applicable apps
2.3 Out of Scope
- Microsoft 365 platform itself — M365 is governed as foundational infrastructure under M365 Workspace & Access Policy (ISMS-POL-M365-01)
- BYOD device-level controls — Governed by BYOD Security Policy (ISMS-POL-BYOD-01). However, app access methods from BYOD devices are subject to both this policy and P2 §7
- Supplier evaluation and contracting — Governed by Supplier & Third-Party Security Policy (ISMS-POL-STP-01) §3
3. Data Context Isolation
3.1 Core Principle
"The nature (Context) of the data determines the account."
Users must select a physically and logically separated account environment based on the ownership and sensitivity of the data they intend to process.
3.2 Context Definitions
| Context | Definition | Account Used | Data Scope |
|---|---|---|---|
| Corporate | Activities that create, access, or process official corporate information assets | Corporate Account | Policy documents, customer data, source code, internal strategy, contracts, etc. |
| Personal | Personal research, learning, and activities based on publicly available materials | Personal Account | Personal research notes, analysis of public materials, learning resources, etc. |
3.3 Core Directive
"Personal accounts are to be used exclusively for personal research and work based on publicly available materials. Official corporate information assets must be handled using corporate accounts on authorised dedicated systems, maintaining complete separation of data contexts between the two."
3.4 Isolation Rules
- Corporate information assets must only be created, stored, and processed within the Corporate Context
- Entering or storing internal source code, customer personally identifiable information (PII), or undisclosed strategic assets within the Personal Context is prohibited
- When both Corporate and Personal accounts are used within the same app, data transfer between accounts (copy/paste, export/import) is prohibited
- Data ownership is determined by the account context — refer to BYOD Security Policy (ISMS-POL-BYOD-01) §6.3
3.5 Alignment with M365 Teams Channel Structure
The Data Context Isolation principle is implemented in the M365 environment through Teams team types and channel structures:
- Even within the Corporate Context, Teams channel types (Standard / Private) are determined by data sensitivity
- Channel structure and data placement rules by team type (Internal Only, Internal Mixed, External Collaboration, Confidential External Sharing) are defined in M365 Workspace & Access Policy (ISMS-POL-M365-01) §5.2–§5.3
- Procedures for external sharing of Confidential-grade data are defined in M365 Workspace Operations Procedure (ISMS-PROC-M365-01) §4
Core Principle: The Context separation (Corporate vs Personal) defined in this policy forms the primary boundary, while the channel classification (General vs Confidential) in the M365 policy forms the secondary boundary. The two boundaries are independent and apply simultaneously.
4. Application Governance Matrix
4.1 Governance Matrix
All approved applications require users to select accounts according to their business context, with assets protected through technical controls.
| Service Category | Target Services | Account Policy | Technical Controls |
|---|---|---|---|
| Core Infrastructure | Microsoft 365 | Corporate Only | IDP-based authentication, ADUE (Azure AD User Enrolment), CA (Conditional Access)/MAM — Governed by P1 |
| Generative AI | Claude, Gemini, etc. | Corporate / Personal Separation | Data training opt-out guaranteed, access via Managed Browser session |
| Knowledge Management | Notion, etc. | Corporate / Personal Separation | Data isolation, restriction on moving internal assets externally |
| Development Assets | GitHub, etc. | Corporate / Personal Separation | Mandatory 2FA (two-factor authentication), device compliance verification |
| Design Assets | Figma, Adobe, etc. | Corporate / Personal Separation | Federated authentication and invite management |
| Collaboration / Finance | Slack, Xero, etc. | Corporate Only | Session expiry policy, IP access restriction (where available) |
4.2 Matrix Management
- The Governance Matrix is managed in alignment with the Approved SaaS Register (P5)
- Upon approval of a new app, the Security Director assigns the account policy and technical control level, and adds the app to the Matrix
- The Matrix is reviewed quarterly, with ad-hoc updates when app changes occur (feature additions, plan changes, etc.)
5. Identity Governance
5.1 Single Source of Trust
- All external service logins must use Entra ID (M365) as the single source of trust
- Services that support SSO (single sign-on) via SAML/OIDC must be configured to integrate with Entra ID
- Services that do not support SSO must, at a minimum, have MFA (multi-factor authentication) enabled
5.2 Federation Principles
- When onboarding services that require authentication via another platform (e.g., Figma requiring Google), corporate account authentication must be integrated via OIDC/SAML Federation rather than creating a separate account
- Where federation is not possible, an independent Corporate account must be created, with MFA enabled and the authentication method recorded in the Approved SaaS Register
5.3 Identity Sprawl Prevention
- Multiple Corporate accounts for the same individual within a single SaaS service are prohibited
- Upon departure or role change, all external SaaS Corporate accounts of the relevant individual must be deactivated or deleted — aligned with the offboarding procedures in Human Resource Security Policy (ISMS-POL-HR-01)
- During quarterly SaaS account audits, inactive accounts (no login for 90+ days) must be identified and remediated
5.4 Collaboration Partner Access
- When external collaborators require access to SaaS apps, the B2B Guest Access model must be applied
- Issuance of internal Corporate accounts to external parties is restricted; access rights are synchronised to the project duration via Guest invitation
- Guest access permissions are managed in accordance with the guest lifecycle defined in Supplier & Third-Party Security Policy (ISMS-POL-STP-01) §4
6. AI Data Sovereignty
6.1 Core Principle
Preventing the leakage and retraining of corporate data when using AI services is the top priority. AI processing of corporate assets must only be conducted in environments where training exclusion is contractually guaranteed.
6.2 AI Use in Corporate Context
When entering corporate information assets into AI services:
- Must be performed under a subscription of Enterprise/Team Plan or higher
- Only use services where training opt-out is contractually guaranteed — refer to P5 §3.3
- Access must be via an ADUE (Azure AD User Enrolment) Managed Browser (Edge) session
- Input data must be reviewed in advance to ensure it does not contain customer PII (personally identifiable information), undisclosed strategic assets, or credentials
6.3 AI Use in Personal Context
When using AI for personal research activities:
- Use a Personal Account, fully separated from the Corporate Context to prevent contamination of corporate logs
- The following inputs are prohibited under any circumstances:
- Internal corporate source code
- Customer PII (personally identifiable information)
- Undisclosed strategic assets, contract content, or financial data
- When bringing outputs from personal AI activities into the Corporate Context, they must be reproduced as corporate assets (rewritten under the corporate account); direct copying of AI output from a personal account is not permitted
6.4 Handling AI Output
- AI-generated content must be treated as a draft only and must undergo Human Review before being used as a final deliverable
- Decisions based on AI output must always include Source Verification
7. Technical Baseline
Current control level under Cybercraft's COM Profile:
- Gateway controls via M365 Conditional Access (CA) and ADUE (Azure AD User Enrolment) device certificates
- SSO-supported services: Entra ID integration configured
- Non-SSO services: Mandatory MFA + policy compliance (NDA, account separation agreement)
- AI services: Enterprise/Team Plan in use, training opt-out guaranteed
Refer to Information Security Policy (ISMS-POL-ISP-01) §2.4 for the Profile framework and transition criteria.
8. Roles and Responsibilities
| Role | Person | Responsibilities |
|---|---|---|
| CISO | Richard | Policy approval, approval of high-risk app operational policies, approval of exceptions related to AI data sovereignty |
| Security Director | Lucas | Governance Matrix management, account separation auditing, identity sprawl review, AI usage monitoring, Profile roadmap execution |
| End User | All users | Adherence to account separation principles, maintaining Context separation when using AI, refraining from use of unapproved apps, reporting anomalies |
9. Compliance Mapping
| ISO 27001 Control | Requirement | Covered By |
|---|---|---|
| A.5.10 | Acceptable use of information and assets | Section 3 (Data Context Isolation) + Section 4 (Governance Matrix) |
| A.5.12 | Classification of information | Section 3.2 (Context Definitions — Corporate vs Personal) |
| A.5.15 | Access control | Section 5 (Identity Governance — SSO, Federation, Sprawl Prevention) |
| A.5.16 | Identity management | Section 5.1 (Single Source of Trust) + Section 5.3 (Identity Sprawl Prevention) |
| A.5.23 | Information security for use of cloud services | Section 4 (Governance Matrix) + Section 6 (AI Data Sovereignty) |
| A.8.11 | Data masking | Section 6.2 (PII pre-screening prior to Corporate AI use) |
| A.8.12 | Data leakage prevention | Section 3.4 (Isolation Rules) + Section 6 (AI Data Sovereignty) |
10. Document Control
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1.0 | 2026-02-20 | Lucas Shin | Initial release — Data Context Isolation principle, Application Governance Matrix, ID Governance (SSO/Federation/Sprawl), AI Data Sovereignty, Technical Roadmap (Tier 1/2). Derived from Security Standards Framework EXT-03 cross-mapping analysis. |
| 0.1.1 | 2026-02-20 | Lucas Shin | L2 policy reordering (renumbered). Updated all cross-reference document numbers and P-numbering to reflect new scheme. |
| 0.1.2 | 2026-02-20 | Lucas Shin | Replaced legacy "Tier 1/Tier 2" terminology with "COM/DEF Profile" to align with updated Security Standards Framework. |
| 0.1.3 | 2026-03-01 | Lucas Shin | Added §3.5 Alignment with M365 Teams Channel Structure — cross-reference between Data Context Isolation and Teams team types/channel structure. Phase 2–5 ISMS document mapping. |