/data-classification

IPAD Data Classification

User Input

$ARGUMENTS

Instructions

Note: The ipad-context hook automatically injects project context (project list, existing artifacts, maturity level) into this command's execution. Use that context to identify the target project directory, project ID, and any existing artifacts.

Step 0: Prerequisite Check

1. Identify the target project from $ARGUMENTS (the project ID, e.g., 001).
2. Verify that an Entity Model artifact (IPAD-{PROJECT_ID}-ENTM-*.md) exists in the project directory. This is a mandatory prerequisite.
3. If the ENTM artifact is missing, stop and inform the user:
   • Explain that data classification requires the entity model to identify all data assets and their attributes that need classification.
   • Suggest running /ipad-kit:entity-model first.
4. Read the ENTM artifact and extract the in-scope entity set, maturity level, domain groupings, and attribute details.
5. Check for and read optional prerequisite artifacts if they exist:
   • Data Catalogue (IPAD-{PROJECT_ID}-DCAT-*.md or .csv) — for attribute-level classification hints and PII flags
   • Assessment (IPAD-{PROJECT_ID}-ASSESS-*.md) — for organisational context and existing data handling practices

Step 1: Read Template

1. Check for a local template override at .ipad/templates/data-classification-template.md.
2. If the local override does not exist, read the default template at ${CLAUDE_PLUGIN_ROOT}/templates/data-classification-template.md.
3. If neither template exists, proceed using the built-in structure defined in these instructions.

Step 2: Read Reference Data

1. Read all entity definition files from ${CLAUDE_PLUGIN_ROOT}/references/framework/entities/ for entities in scope, paying particular attention to attribute sensitivity indicators and PII presence.
2. Read ${CLAUDE_PLUGIN_ROOT}/references/framework/governance/ica-security.md for the ICA security model and the 4-tier classification taxonomy (PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED).
3. Read ${CLAUDE_PLUGIN_ROOT}/references/framework/governance/roles-and-responsibilities.md for classification governance roles and approval authority.
4. Read ${CLAUDE_PLUGIN_ROOT}/references/framework/standards/dama-dmbok-mapping.md for Data Security knowledge area alignment.

Step 3: Apply Classification Logic

1. Classify each entity at the entity level based on the most sensitive attribute it contains.
2. Then perform attribute-level classification for entities where attributes span multiple classification tiers.
3. Apply these classification heuristics:
   • PUBLIC: Aggregated statistics, published indices, general country/sector profiles (e.g., E-001 jurisdiction profiles, E-007 macroeconomic indicators already in public domain)
   • INTERNAL: IPA operational data not intended for public release (e.g., E-016 marketing campaigns, E-042 KPI definitions, E-046 interaction logs)
   • CONFIDENTIAL: Investor-specific data, commercial intelligence, personal data (e.g., E-021 investor organisations, E-022 investor contacts, E-028 investment projects, E-036 economic impact assessments)
   • RESTRICTED: National security data, highly sensitive policy deliberations, classified intelligence (e.g., E-039 investment policies under development, E-049 economic cooperation agreements under negotiation)

Step 4: Generate Data Classification

Produce the following sections in the output artifact:

4.1 Document Information

Auto-populate the following fields at the top of the document:

• Document ID: IPAD-{PROJECT_ID}-DCLS-v1.0
• Project: {project name from context}
• Date: {current date}
• Status: Draft
• Prerequisites Used: List the ENTM, DCAT, ASSESS, and any other artifacts read

4.2 Executive Summary

Overview of the classification exercise — total entities classified, distribution across tiers, PII exposure percentage, and key findings.

4.3 Classification Taxonomy

Define the 4 tiers with IPA-specific definitions, examples, and impact if breached:

Tier	Definition	IPA Examples	Impact if Breached
PUBLIC	Data intended for or already in the public domain	Published FDI statistics, country profiles, public rankings	Minimal — data is already public
INTERNAL	IPA operational data not for external release	Campaign plans, internal KPIs, staff allocations, event logistics	Moderate — competitive disadvantage, operational disruption
CONFIDENTIAL	Sensitive business, investor, or personal data	Investor details, project pipelines, commercial terms, PII	Significant — regulatory penalty, investor trust loss, reputational damage
RESTRICTED	National security or highly sensitive policy data	Undisclosed policy positions, intelligence briefings, ongoing negotiations	Severe — national security risk, diplomatic impact

4.4 Entity Classification Matrix

Table classifying every in-scope entity:

• Entity ID | Entity Name | Domain | Entity-Level Classification | Justification | Contains PII | Contains Mixed Classifications | Review Priority

4.5 Attribute-Level Classification

For entities where different attributes have different classification tiers, provide a detailed breakdown:

• Entity ID | Entity Name | Attribute | Attribute Classification | Entity Classification | Reason for Difference
• Example: E-021 Investor Organisation might have sector = PUBLIC but investment_amount = CONFIDENTIAL and contact_email = CONFIDENTIAL (PII)

4.6 Composite Data Rule

Document the rule that when data from different classification tiers is combined, the resulting dataset inherits the highest classification tier of any contributing data element. Provide concrete IPA examples:

• Joining PUBLIC country data with CONFIDENTIAL investor data produces a CONFIDENTIAL dataset
• Aggregating CONFIDENTIAL project data into anonymised statistics may produce INTERNAL data (with formal de-identification approval from CDO)
• Cross-referencing RESTRICTED policy data with any other tier produces a RESTRICTED dataset

4.7 PII Identification Register

Comprehensive table of all attributes flagged as personally identifiable information:

• Entity ID | Entity Name | Attribute | PII Category (Personal Name / Contact Information / Financial Data / National Identifier / Location Data / Professional Data / Behavioural Data) | Classification | Legal Basis for Processing | Retention Period | Anonymisation Feasibility

4.8 Classification by Domain

Summary view per business domain:

• Domain | Total Entities | PUBLIC | INTERNAL | CONFIDENTIAL | RESTRICTED | PII Entities | Dominant Tier

4.9 Handling Requirements by Tier

For each classification tier, define:

• Access Controls: PUBLIC (open access) / INTERNAL (role-based, IPA staff, standard auth) / CONFIDENTIAL (need-to-know, named role authorisation, MFA) / RESTRICTED (named individual authorisation, security clearance, audit trail)

• Encryption: PUBLIC (optional for integrity) / INTERNAL (at rest + in transit, TLS 1.2+) / CONFIDENTIAL (mandatory AES-256 at rest, TLS 1.3 in transit, key management) / RESTRICTED (mandatory enhanced encryption, HSM key storage, end-to-end)

• Retention and Disposal: Retention periods per tier aligned with IPA data retention policy and local regulations; disposal methods (logical deletion, cryptographic erasure, physical destruction); archival requirements before disposal

• Audit Requirements: PUBLIC (none) / INTERNAL (annual access review) / CONFIDENTIAL (semi-annual access review, access logging) / RESTRICTED (quarterly access review, comprehensive audit trail, security incident monitoring)

4.10 Cross-Border Considerations

• Data sovereignty requirements for the IPA's jurisdiction
• International data transfer restrictions (GDPR equivalents, bilateral data agreements)
• Cloud hosting implications (data residency requirements per classification tier)
• Cross-border data sharing with international organisations (UNCTAD, OECD, World Bank)
• Special considerations for investor data originating from foreign jurisdictions
• Adequacy decisions, standard contractual clauses, and binding corporate rules

4.11 Classification Lifecycle

• Initial classification at data creation/ingestion
• Periodic review cadence: PUBLIC (annual) / INTERNAL (annual) / CONFIDENTIAL (semi-annual) / RESTRICTED (quarterly)
• Reclassification triggers: policy change, regulatory change, data aggregation, time-based declassification, change of use
• Classification dispute resolution process and escalation path

4.12 Mermaid Classification Summary

pie chart showing distribution of in-scope entities across classification tiers. Include a second pie chart showing PII vs non-PII distribution.

Step 5: Write Output

1. Write the completed artifact to projects/{project-dir}/IPAD-{PROJECT_ID}-DCLS-v1.0.md.
2. If a previous version exists, increment the minor version (e.g., v1.0 -> v1.1).
3. Append the generation metadata footer:

---
**Generated by**: IPAD Kit `/ipad-kit:data-classification` command
**Generated on**: {DATE}
**IPAD Kit Version**: {IPAD_KIT_VERSION}
**Project**: {PROJECT_ID}-{project-name}

Step 6: Present Summary and Next Steps

1. Confirm the artifact was written successfully.
2. Display a summary: classification distribution, PII entity count, mixed-classification entity count.
3. Highlight entities classified as RESTRICTED that require immediate security review.
4. Note the PII exposure summary and recommend a data protection impact assessment if significant PII is identified.
5. Flag any entities where attribute-level classification varies significantly (mixed classification entities) as these require careful access control design.
6. Warn about composite data implications for reporting and analytics workloads.
7. Recommend next commands:
   • /ipad-kit:security — Define security controls aligned to each classification tier
   • /ipad-kit:governance — Formalise classification governance, review cadence, and dispute resolution