---
tags:
  - project/iso27DIY
  - dev
  - graphDB
  - dbms
  - design
---

# TypeDB structure for ISO27DIY
 

**Prompt for Gemini** 

You are an information consultant specialized in TypeDB databases. I am the client. 

I need a TypeDB database for all the information on clauses and controls of ISO 27001 and 27002. 
The information that is important to me, and for which I need to be able to query the database, is:
- the identifiers and titles of controls in the annexes 
- The purpose of controls
- The implementation guidance for controls
- The actors involved in the implementation, evaluation and approval of controls 
- The artifacts needed to prove implementation 
- The actions and processes described in the chapters/clauses from the main body of ISO 27001 and 27002
- The relationship between these entities or objects. 

You will write the TypeQL declarative patterns to describe the database structure.

## Output
Okay, client. Based on the provided ISO 27001 and ISO 27002 source materials, I will outline a TypeDB schema using TypeQL declarative patterns to represent the information you've requested. This schema will allow you to query relationships between standards, clauses, controls, actors, artifacts, requirements, risks, events, and processes as described in the sources.
Here is the schema definition:
define

// ATTRIBUTES

// Common Identifiers and Names
identifier sub attribute, value type string;
title sub attribute, value type string;
name sub attribute, value type string;

// Text Descriptions
description sub attribute, value type string;
purpose-text sub attribute, value type string;
guidance-text sub attribute, value type string;
content sub attribute, value type string; // For artifact content (e.g., policy text)
text sub attribute, value type string; // For requirement text

// Control Specific Attributes
control-type sub attribute, value type string; // e.g., #Preventive, #Detectif, #Corrigerend
security-property sub attribute, value type string; // e.g., #Vertrouwelijkheid, #Integriteit, #Beschikbaarheid
cybersecurity-concept sub attribute, value type string;
operational-capability sub attribute, value type string;
security-domain sub attribute, value type string;

// Actor Specific Attributes
actor-type sub attribute, value type string; // e.g., 'organization', 'person', 'external-party'
external-party-type sub attribute, value type string; // e.g., 'supplier', 'authority', 'special-interest-group', 'cloud-provider'
role-name sub attribute, value type string; // e.g., 'implementer', 'approver', 'owner', 'user', 'responsible', 'evaluator', 'party'

// Asset Specific Attributes
asset-type sub attribute, value type string; // e.g., 'information', 'IT-asset', 'physical-asset', 'service'
sensitivity-level sub attribute, value type string;
current-classification sub attribute, value type string; // Links to Classification level name

// Artifact Specific Attributes
artifact-type sub attribute, value type string; // e.g., 'policy', 'procedure', 'record', 'plan', 'agreement', 'schema', 'evidence', 'documentation', 'inventory-list'
is-documented sub attribute, value type boolean;
approval-status sub attribute, value type string; // e.g., 'approved', 'draft'
approval-level sub attribute, value type string; // e.g., 'management', 'board'
review-period sub attribute, value type string; // e.g., 'annual', 'biannual'

// Requirement Specific Attributes
requirement-source sub attribute, value type string; // e.g., 'legal', 'regulatory', 'contractual', 'stakeholder', 'business'

// Risk Specific Attributes
risk-type sub attribute, value type string; // e.g., 'information security risk', 'privacy risk'

// Event Specific Attributes
event-type sub attribute, value type string; // e.g., 'information security event', 'information security incident', 'disruption'
category sub attribute, value type string; // e.g., Incident categorization schema value
priority sub attribute, value type string; // e.g., Incident prioritization schema value

// Process Specific Attributes
process-name sub attribute, value type string; // Using name attribute for processes

// Standard Specific Attributes
standard-version sub attribute, value type string;

// ENTITIES

// Represents ISO standards like 27001 or 27002
standard sub entity,
    owns identifier @key, // e.g., "ISO/IEC 27001", "ISO/IEC 27002"
    owns standard-version; // e.g., "2022", "2023"

// Represents clauses within the main body of a standard (e.g., ISO 27001 Clauses 4-10, ISO 27002 Clauses 5-8 as presented)
clause sub entity,
    owns identifier @key, // e.g., "4", "5.1" (if modeling 27001 control clauses)
    owns title, // e.g., "Context of the organization", "Policies for information security"
    owns description; // Content text from the clause

// Represents information security controls, primarily from ISO/IEC 27002
control sub entity,
    owns identifier @key, // e.g., "5.9", "8.4"
    owns title, // e.g., "Inventory of information and other associated assets"
    owns purpose-text,
    owns guidance-text,
    owns control-type,
    owns security-property,
    owns cybersecurity-concept,
    owns operational-capability,
    owns security-domain;

// Abstract type for any entity that can perform actions or have responsibilities
actor sub entity,
    owns actor-type @key; // Discriminator: 'organization', 'person', 'external-party'

organization sub actor, owns name @key;
person sub actor, owns name @key;
external-party sub actor,
    owns name @key,
    owns external-party-type; // 'supplier', 'authority', 'special-interest-group', etc.

// Represents information and other associated assets
asset sub entity,
    owns name @key, // e.g., "Customer Database", "Laptop", "Cloud Storage Service"
    owns asset-type,
    owns sensitivity-level,
    owns current-classification; // Refers to a Classification level (string for simplicity here)

// Represents documentation, records, plans, agreements, schemas, evidence
artifact sub entity,
    owns name @key, // e.g., "Information Security Policy", "Supplier Agreement XYZ", "Risk Assessment Report"
    owns artifact-type,
    owns content,
    owns is-documented,
    owns approval-status,
    owns approval-level,
    owns review-period;

// Represents legal, regulatory, contractual, business, or stakeholder requirements
requirement sub entity,
    owns text @key,
    owns requirement-source; // e.g., 'legal', 'contractual', 'business'

// Represents information security risks
risk sub entity,
    owns description @key,
    owns risk-type;

// Represents information security events or incidents
event sub entity,
    owns event-type @key, // e.g., 'information security event', 'information security incident', 'disruption'
    owns description,
    owns category,
    owns priority;

// Represents business processes or information security management processes
process sub entity,
    owns process-name @key, // e.g., "Risk Assessment Process", "Incident Management Process"
    owns description;

// RELATIONS

// Standard Structure: Clause and Control are part of a Standard
part-of-standard sub relation,
    clause-part owns identifier, // Role for clause identifier
    control-part owns identifier, // Role for control identifier
    standard-part owns identifier; // Role for standard identifier
clause part-of-standard: clause-part;
control part-of-standard: control-part;
standard part-of-standard: standard-part;

// Relationships describing who defines/creates artifacts
defines-artifact sub relation,
    definer plays actor,
    defined-artifact plays artifact;

// Relationship describing who implements controls or requirements
implements sub relation,
    implementer plays actor,
    implemented-subject plays control | requirement; // Can implement controls or requirements

// Relationship describing responsibility for controls, assets, processes, artifacts
responsible-for sub relation,
    responsible plays actor,
    responsibility-subject plays control | asset | process | artifact,
    owns role-name; // e.g., 'owner', 'manager', 'coordinator'

// Relationship describing who approves artifacts (e.g., management approves policies)
approves sub relation,
    approver plays person, // Typically a person (management)
    approved-artifact plays artifact,
    owns approval-level;

// Relationship describing who evaluates what (e.g., organization evaluates supplier, manager evaluates compliance)
evaluates sub relation,
    evaluator plays actor,
    evaluated-subject plays actor | control | asset | process | artifact, // Evaluate other actors, controls, assets, processes, artifacts
    owns role-name; // e.g., 'internal-reviewer', 'independent-reviewer'

// Relationship describing how requirements or risks are addressed
addresses sub relation,
    subject-to-address plays requirement | risk,
    addressing-method plays control | process | artifact; // Controls, processes, or artifacts address requirements/risks

// Relationship between assets
associated-with sub relation,
    asset-a plays asset,
    asset-b plays asset;

// Relationship describing who uses assets
uses-asset sub relation,
    user plays actor | process, // Actors or processes use assets
    used-asset plays asset;

// Relationship describing who accesses assets (specifically information/data)
accesses-asset sub relation,
    accessor plays actor,
    accessed-asset plays asset; // Typically asset type 'information' or asset with information

// Relationship describing what is covered by an agreement artifact
covered-by-agreement sub relation,
    subject plays asset, // Assets or services covered
    agreement plays artifact; // Artifact type 'agreement'

// Relationship describing actors and artifacts involved in a process
involved-in-process sub relation,
    participant plays actor,
    process plays process,
    owns role-name; // e.g., 'responsible', 'contributor'
artifact involved-in-process: process-artifact; // Role for artifacts used in processes (input/output/tool)
process involved-in-process: process;
actor involved-in-process: participant;

// Relationship between processes/assets/persons and events (e.g., incident impacts asset)
relates-to-event sub relation,
    subject plays process | asset | person, // What is related to the event
    event plays event,
    owns role-name; // e.g., 'impacted-asset', 'involved-person', 'triggering-process'

// Relationship describing controls or processes active during disruption events
during-disruption sub relation,
    subject plays control | process, // Controls or processes
    disruption-event plays event; // Event type 'disruption'

// Relationship describing plans or requirements informed by analysis artifacts
informed-by-artifact sub relation,
    subject plays artifact | requirement, // Plan artifact or Requirement
    informing-artifact plays artifact; // Analysis results artifact (e.g., BIA report)

// General relationship for using artifacts
uses-artifact sub relation,
    user plays actor | process,
    used-artifact plays artifact;

// Relationship describing artifacts serving as evidence for control/clause/requirement/process implementation or compliance
serves-as-evidence-for sub relation,
    evidence plays artifact,
    subject plays control | clause | requirement | process;

// Relationship for cross-referencing between controls
references-control sub relation,
    referencing-control plays control,
    referenced-control plays control;

// Relationship describing how controls, processes, or organizations meet requirements
meets-requirement sub relation,
    subject plays control | process | organization,
    requirement plays requirement;

// Relationship linking requirements back to the clause they are found in (if applicable)
requirement-in-clause sub relation,
    requirement plays requirement,
    clause plays clause;

## Explanation of the Schema

**Attributes:** These define the properties that entities can have, such as identifier, title, purpose-text, guidance-text, name, type, etc. Each attribute is defined with its value type (e.g., string, boolean). Some attributes are marked @key within an entity definition, meaning they uniquely identify instances of that entity type.
**Entities:** These are the main objects or concepts in your database, like standard, control, organization, asset, artifact, etc. They own attributes to describe their properties.
**Relations:** These define how entities relate to each other. Each relation defines roles that entities play in that relationship. For example, in the responsible-for relation, an actor plays the responsible role for a subject(which could be a control, asset, process, or artifact), and the relation itself owns a role-name attribute to specify the nature of that responsibility (e.g., 'owner', 'manager').

**How this Schema Addresses Your Needs:**

**Identifiers and titles of controls:** Captured by the control entity with identifier and title attributes.
**Purpose of controls:** Captured by the control entity with the purpose-text attribute.
**Implementation guidance for controls:** Captured by the control entity with the guidance-text attribute.
**Actors involved in the implementation, evaluation and approval of controls:** Captured by the actor entities (organization, person, external-party) and relationships like implements, evaluates, responsible-for, and approves. The role-name attribute on relationships like responsible-for and evaluates allows specifying the exact role (e.g., 'implementer', 'reviewer', 'approver').
**Artifacts needed to prove implementation:** Captured by the artifact entity and the serves-as-evidence-forrelationship, linking an artifact instance to the control, clause, requirement, or process it provides evidence for.
**Actions and processes described in the chapters/clauses:** Captured by the clause entity (holding the text description), the process entity, and relationships like involved-in-process which links actors and artifacts to specific processes described.
**The relationship between these entities or objects:** Defined explicitly by the TypeQL relations, allowing you to traverse the graph and discover how different concepts are connected according to the sources. For example, you can find which controls are implemented by a specific organization (implements relation), which artifacts are required for a control (serves-as-evidence-for relation), or which personnel are involved in an incident management process (involved-in-process relation).
This schema provides a solid foundation for building your TypeDB database based on the ISO 27001 and 27002 sources you provided. You can populate this schema with instances derived from the text (e.g., create an organization instance, a control instance for 5.9, an artifact instance for an Inventory List, and link them using the defined relations).

## Mermaid diagram

Syntax errors:
- the bracketed numbers, e.g. `risk [3]`
- `note over` seems to confuse the parser

```
graph TD
    standard{{"Standard<br/>identifier @key<br/>title"}}
    clause{{"Clause<br/>identifier @key<br/>title<br/>text"}}
    requirement{{"Requirement<br/>identifier @key<br/>text"}}
    control{{"Control<br/>identifier @key<br/>title<br/>purpose-text<br/>guidance-text"}}
    organization{{"Organization<br/>name @key"}}
    person{{"Person<br/>name @key"}}
    external_party{{"External Party<br/>name @key"}}
    asset{{"Asset<br/>name @key<br/>type"}}
    artifact{{"Artifact<br/>name @key<br/>type"}}
    risk{{"Risk<br/>identifier @key<br/>description"}}
    event{{"Event<br/>identifier @key<br/>description"}}
    process{{"Process<br/>identifier @key<br/>description"}}

    standard -- "defines clause" --> clause
    clause -- "part-of standard" --> standard
    clause -- "contains requirement" --> requirement
    requirement -- "part-of clause" --> clause
    requirement -- "addressed-by control" --> control
    control -- "addresses requirement" --> requirement

    risk -- "treated-by control" --> control
    control -- "treats risk" --> risk [3]

    organization -- "implements control" --> control [2]
    person -- "implements control" --> control [2]
    external_party -- "implements control" --> control [2]

    organization -- "evaluates control" --> control [2]
    person -- "evaluates control" --> control [2]
    external_party -- "evaluates control" --> control [2]

    organization -- "approves control" --> control [2]
    person -- "approves control" --> control [2]
    external_party -- "approves control" --> control [2]

    organization -- "responsible-for subject" --> control [2]
    organization -- "responsible-for subject" --> asset [2]
    organization -- "responsible-for subject" --> process [2]
    organization -- "responsible-for subject" --> artifact [2]

    person -- "responsible-for subject" --> control [2]
    person -- "responsible-for subject" --> asset [2]
    person -- "responsible-for subject" --> process [2]
    person -- "responsible-for subject" --> artifact [2]

    external_party -- "responsible-for subject" --> control [2]
    external_party -- "responsible-for subject" --> asset [2]
    external_party -- "responsible-for subject" --> process [2]
    external_party -- "responsible-for subject" --> artifact [2]

    organization -- "involved-in process" --> process [2]
    person -- "involved-in process" --> process [2]
    external_party -- "involved-in process" --> process [2]
    artifact -- "involved-in process" --> process [2]

    artifact -- "serves-as-evidence-for subject" --> control [2]
    artifact -- "serves-as-evidence-for subject" --> clause [2]
    artifact -- "serves-as-evidence-for subject" --> requirement [2]
    artifact -- "serves-as-evidence-for subject" --> process [2]

    event -- "managed-by control" --> control [4, 5]
    control -- "manages event" --> event [4, 5]

    asset -- "protected-by control" --> control [6]
    control -- "protects asset" --> asset [6]

    note over organization, person, external_party: Actors are Organization, Person, External Party [2]
    note over control, asset, process, artifact: The 'responsible-for' relation has a 'role-name' attribute (e.g., 'owner', 'manager') [1, 2]
    note over control, clause, requirement, process: The 'serves-as-evidence-for' relation links Artifacts to these subjects [2]
```

## Explanation of Mermaid diagram

- The diagram visualizes the entities identified in the schema such as `standard`, clause, `control`, `organization`, `person`, `external-party`, `asset`, `artifact`, `risk`, `event`, and `process`.
* Some of the key attributes mentioned in the schema definition are listed within the entity nodes (e.g., `identifier @key`, `title`, `purpose-text`, `guidance-text`). Attributes marked with `@key` are unique identifiers for entity instances.
* The arrows represent the **Relations** defined in the schema. Each relation connects entities and the labels on the arrows indicate the name of the relation (e.g., `defines`, t`reated-by`) and the **Role** that the entity at the start of the arrow plays in that relationship (e.g., `defines clause`, `treated-by control`).
* Specific relationships are shown as described or implied by the sources:
  * Standards define clauses.
  * Clauses contain requirements.
  * Requirements are addressed by controls.
  * Risks are treated by controls.
  * Actors (`organization`, `person`, `external-party`) can implement, evaluate, or approve controls. These are specific types of actors mentioned in the sources.
  * Actors can be responsible for controls, assets, processes, and artifacts. This relation type (`responsible-for`) includes a role-nameattribute in the schema to specify the nature of responsibility (e.g., 'owner', 'manager').
  * Actors and artifacts can be involved in processes. The term 'process' is defined as a set of interrelated activities.
  * Artifacts serve as evidence for controls, clauses, requirements, or processes. Records, a type of artifact, are information maintained as evidence.
  * Controls can manage events.
  * Controls can protect assets. An asset can be a bedrijfsmiddel. Assets include information and other related items.

This diagram provides a visual representation of how the different components of the ISO 27001/27002 framework, as mapped into a TypeDB schema, are intended to interrelate according to the sources. The structure allows for querying and traversing these connections to understand the relationships between requirements, the controls implemented to meet them, the risks they address, the assets involved, the processes they are part of, the actors responsible, and the artifacts serving as evidence

# Graph db’s for PoC
Building a Proof of Concept (POC) for a Knowledge Graph in Information Security and Compliance on a Mac Mini M2, with an eye towards LLM integration, requires a robust, well-maintained, and performant open-source property graph database.
Here are the top contenders, focusing on your specific criteria:
Top Choices for Your POC
* Neo4j Community Edition
  * Pros:
    * Gold Standard: Neo4j is arguably the most widely recognized and mature property graph database. It has a massive community, extensive documentation, and a wealth of learning resources (GraphAcademy).
    * Cypher Query Language: Cypher is a highly intuitive and powerful declarative query language specifically designed for property graphs. It's excellent for expressing complex patterns and traversals, which is ideal for security and compliance use cases (e.g., "find all assets vulnerable to a specific threat, mitigated by a weak control, and subject to GDPR").
    * M2 Compatibility: Neo4j Desktop (which includes the Community Edition) runs natively on macOS, including Apple Silicon (M1/M2/M3), making installation and local development very smooth. You can also run it via Docker.
    * Strong LLM Integration Ecosystem: Neo4j has heavily invested in LLM integrations. They have a dedicated "GraphRAG" initiative, LangChain integrations, and many tutorials showing how to use LLMs for knowledge graph construction (extracting entities and relationships from unstructured text) and for generating natural language queries from human questions. This ecosystem is probably the most mature for LLM interaction.
    * Visualization: Neo4j Browser provides excellent built-in visualization, which is crucial for understanding complex security relationships in a knowledge graph.
  * Cons:
    * Licensing: The Community Edition is open source under GPLv3, but some advanced features (like clustering for high availability/scalability) are only in the Enterprise Edition (commercial license). For a POC, this isn't usually an issue.
* Memgraph Community Edition
  * Pros:
    * High Performance (In-Memory): Memgraph is an in-memory graph database, making it exceptionally fast for queries and real-time analytics. This could be a significant advantage for dynamic security analysis or incident response simulations.
    * OpenCypher Support: It supports OpenCypher, making it compatible with Neo4j's powerful query language. This allows for easy migration if you later decide to switch or leverage existing Cypher knowledge.
    * M2 Compatibility: Runs well on macOS (including M2), often installed via brew.
    * Good LLM Integration: Memgraph has actively promoted its use in GraphRAG applications and offers integrations with tools like LangChain for LLM interaction, similar to Neo4j.
    * MAGE (Memgraph Advanced Graph Extensions): Provides a library of graph algorithms that can be very useful for advanced security analytics (e.g., finding central assets, identifying attack paths).
  * Cons:
    * In-Memory (for POC): While fast, being primarily in-memory means you'll need to be mindful of the Mac Mini's RAM limitations for very large datasets in a long-running POC. However, for a typical POC scope, this is often manageable. Persistent storage is supported, but the core strength is in-memory.
    * Smaller Community: While growing, its community is smaller than Neo4j's.
* Apache AGE (PostgreSQL Extension)
  * Pros:
    * Leverages PostgreSQL: If you're already familiar with PostgreSQL or want to keep your graph data alongside relational data, AGE is a compelling choice. It offers the ACID compliance and robustness of Postgres.
    * Cypher-like Querying: It provides a Cypher-like query language (called age_graph_query) within SQL, allowing you to run graph queries directly on your Postgres database.
    * M2 Compatibility: As a PostgreSQL extension, it runs wherever PostgreSQL runs, including natively on Mac Mini M2.
    * Apache Project: Being an Apache project means it's community-driven and open-source with a clear governance model.
  * Cons:
    * Less Native Graph Performance: While good, it's an extension to a relational database, so its raw graph traversal performance might not match native graph databases like Neo4j or Memgraph for extremely deep or complex traversals.
    * LLM Integration Maturity: While you can certainly integrate it with LLMs via custom code (e.g., using LangChain and a PostgreSQL connector), the specific "GraphRAG" tools and tutorials might be less direct compared to Neo4j's dedicated ecosystem. You'd be building more of that integration yourself.
Key Considerations for Your POC
* Ease of Setup/Local Development on Mac Mini M2: All options listed are generally easy to install via Homebrew or Docker on Apple Silicon.
* Query Language: Both Neo4j and Memgraph use (or support) Cypher, which is excellent for security knowledge graphs. Apache AGE uses a Cypher-like syntax.
* LLM Integration (MPC Server):
  * Data Extraction: LLMs can be used to extract entities (assets, vulnerabilities, controls, regulations) and relationships from unstructured text (e.g., security reports, compliance documents, threat intelligence). Your chosen graph database will then store this structured data.
  * Retrieval Augmented Generation (RAG): This is where the "MPC server" comes in. Your LLM application will query the knowledge graph to retrieve relevant context (e.g., "what controls mitigate this vulnerability for these assets?") and feed that context to the LLM to generate more accurate and grounded responses (e.g., "Here's how to address CVE-X affecting your web server, according to NIST CSF control AC-3").
  * Text-to-Graph/Graph-to-Text: LLMs can also help translate natural language questions into graph queries (e.g., "show me my compliance posture for PCI DSS" -> Cypher query) and translate graph query results back into human-readable text.
  * Vector Search: Many modern graph databases are integrating vector capabilities. This allows you to store embeddings (numerical representations) of nodes and relationships, enabling semantic search and similarity matching, which is very useful for LLM applications.
Recommendation for POC:
For a POC on a Mac Mini M2 with a strong focus on LLM integration for InfoSec/Compliance, Neo4j Community Edition is often the safest and most feature-rich choice.
* Its mature ecosystem, dedicated GraphRAG tools, and intuitive Cypher language will significantly accelerate your development and experimentation with LLMs.
* The community support and wealth of online resources mean you'll likely find solutions to problems quickly.
* The visualization capabilities are excellent for demonstrating the value of the knowledge graph to stakeholders.
If you hit performance bottlenecks with Neo4j (which is unlikely for a typical POC unless your dataset is truly massive), or if you have a strong existing PostgreSQL ecosystem you want to leverage, then Memgraph (for raw speed) or Apache AGE (for PostgreSQL integration) are excellent alternatives.

