Entity Dictionary¶
Draft v0.1
This page is in draft. Content may change before v1.0.
Canonical definitions for the eight core entities in the ACES data model. Each entry includes the canonical name, definition, alternate names observed in production codebases, and the canonical field set.
1. Tenant¶
Definition: An organization whose compliance posture is being assessed. In MSP deployments, tenants exist at two levels: the MSP (service provider) and the client (end organization). Both levels must be present to uniquely scope any compliance record.
Alternate names observed: company, msp, organization, tenant, customer, partner, account
Canonical fields:
| Field | Type | Description |
|---|---|---|
company_id | string | MSP / top-level tenant identifier |
client_id | string | End-client identifier within MSP |
company_name | string | MSP display name |
client_name | string | End-client display name |
external_org_id | string | Connector-assigned org identifier |
external_org_name | string | Connector-assigned org name |
Two-Level Hierarchy
company_id alone is not sufficient to scope evidence in multi-tenant MSP deployments. Both company_id and client_id are required on every record.
2. Connector¶
Definition: A configured integration between a compliance platform and a source security tool. A Connector belongs to a Connector Type (the product/vendor) and is instantiated per client. It produces Metric rows when it runs a collection.
Alternate names observed: integration, tool, provider, data_source, sync, plugin, adapter
Canonical fields:
| Field | Type | Description |
|---|---|---|
connector_type_id | string | Slug of the connector type (e.g. huntress) |
security_connector_id | string | Unique instance ID for this client's configured connector |
display_name | string | Human-readable connector name |
vendor | string | Vendor/product name |
category | enum | vulnerability \| edr \| dlp \| siem \| asset \| benchmark \| pii_discovery \| access_audit |
auth_type | enum | api_key \| oauth2 \| basic \| certificate |
last_sync_at | datetime | Last successful collection timestamp |
last_sync_status | enum | pending \| in_progress \| success \| failed \| partial |
is_active | boolean | Whether connector is enabled |
is_configured | boolean | Whether credentials have been entered |
is_verified | boolean | Whether credentials have been tested successfully |
Known connector type slugs (production): auvik, breachsecurenow, cyberhoot, connectsecure, domainscanner, huntress, hudu, liongard, msgraph, ncentral, ninjarmm, nodeware, phin, senteon, sentinelone, symbol, threatlocker, cavelo, m365
3. Evidence¶
Definition: A record that a specific security control is or is not being met, backed by verifiable data from a source tool or human attestation. Evidence may be a file (PDF, screenshot, export) or a structured metric collection from an automated connector.
Alternate names observed: artifact, document, proof, attestation, record, finding_support, evidence_file, assessment_evidence
Canonical fields:
| Field | Type | Description |
|---|---|---|
id | string (ULID) | Unique evidence identifier |
company_id | string | MSP tenant |
client_id | string | End-client tenant |
connector_type_id | string | Source connector type |
security_connector_id | string | Source connector instance |
evidence_type | string | Free-form category (see Evidence Schema) |
evidence_location | string | URL or file path |
evidence_location_type | enum | file_path \| text |
upload_source | enum | onedrive \| sharepoint \| sharepoint-gcc \| googledrive \| local \| auto_generated |
hash_value | string | File integrity hash |
hash_algorithm | enum | SHA256 \| SHA512 \| MD5 |
is_tampered | boolean | Tamper detection flag |
is_verified | boolean | Human-verified flag |
verified_at | datetime | Verification timestamp |
collected_at | datetime | When evidence was collected |
4. Control¶
Definition: A specific security requirement within a framework. A Control defines what must be done; Evidence demonstrates whether it is being done. Controls belong to a Framework and may belong to one or more categories and subcategories.
Alternate names observed: requirement, item, question, practice, safeguard, objective, check, assessment_item
Canonical fields:
| Field | Type | Description |
|---|---|---|
control_id | string | Machine-readable identifier (e.g. AC.L2-3.1.2) |
control | text | Full control text / question |
control_objective_id | string | Parent objective identifier |
control_objective_item | string | Objective item text |
category | string | Domain/domain group (e.g. Access Control) |
subcategory | string | Sub-domain or practice area |
explanation | string | Additional guidance text |
scoring_instructions | text | Assessor scoring guidance |
sprs_score | smallint | CMMC SPRS weight: 1, 3, or 5 |
examine | string | NIST 800-171A examine method |
interview | string | NIST 800-171A interview method |
test | string | NIST 800-171A test method |
sequence | smallint | Display order |
5. Framework¶
Definition: A named compliance standard or policy pack that organizes Controls into a structured assessment. Frameworks may be system-defined (CIS, CMMC, SOC 2), vendor-tool-sourced, or custom.
Alternate names observed: policy_pack, risk_management_framework, standard, compliance_framework, assessment_type, program
Canonical fields:
| Field | Type | Description |
|---|---|---|
key | string | Machine-readable slug (e.g. cmmc-level2) |
name | string | Display name |
version | string | Version string (e.g. 2.0) |
category | string | Framework category (e.g. general) |
source | enum | system \| vendortool \| custom |
is_active | boolean | Whether framework is available for use |
is_sprs | boolean | Whether framework uses SPRS scoring |
description | text | Framework description |
Known framework keys (production): nist-csf, nist-800-171, cmmc-level1, cmmc-level2, soc-2, iso-27001, pci-dss, hipaa, gdpr, cis-v8, ftc-safeguards
6. Finding¶
Definition: The result of evaluating a Control against available Evidence for a specific Tenant at a point in time. A Finding records not just the score but the RACI, conformity mark, auditor notes, and implementation details.
Alternate names observed: assessment_question_result, control_result, question_response, control_response, assessment_item_result
Canonical fields:
| Field | Type | Description |
|---|---|---|
assessment_event_id | string | Parent assessment run |
question_id | string | Source control/question |
selected_option_id | string | Chosen answer option (maps to a score) |
responsibility | enum | msp \| company \| shared \| tool |
srm | string | msp \| client \| shared |
auditor_conformity_mark | string | met \| not met |
auditor_notes | text | Third-party auditor observations |
implementation_statement | text | How control is implemented |
policy_statement | text | Supporting policy |
procedure_statement | text | Supporting procedure |
evidence_location | text | Evidence reference |
evidence_location_type | enum | file_path \| text |
sprs_score | smallint | CMMC SPRS weight |
sprs_value | integer | SPRS numeric contribution |
control_owner_id | string | Responsible user |
vendor | string | Satisfying vendor |
tool | string | Satisfying tool |
7. Score¶
Definition: A numeric summary of compliance coverage for a Control, domain, or Framework, derived from Findings. Scores exist at multiple granularities and use a traffic-light band model for display.
Alternate names observed: compliance_score, assessment_score, grade, rating, percentage, result
Canonical fields:
| Field | Type | Description |
|---|---|---|
score | smallint | Overall numeric score (on assessment_events) |
value | decimal(7,2) | Points earned for an answer option |
possible_points | decimal(7,2) | Maximum points available for an answer option |
min_score | decimal(7,3) | Lower bound of a scoring band |
max_score | decimal(7,3) | Upper bound of a scoring band |
color | string | Traffic light color for display band |
limit | enum | lowest \| middle \| highest — boundary rule |
sprs_value | integer | CMMC SPRS total (DoD methodology, base: 110) |
Score display conventions (observed):
| Range | Label | Color |
|---|---|---|
| 90–100 | Compliant | Green |
| 75–89 | Mostly Compliant | Yellow |
| 50–74 | Partially Compliant | Orange |
| 0–49 | Non-Compliant | Red |
| N/A | No Evidence | Grey |
8. Asset¶
Definition: A device, system, or identity that is subject to security controls and can be a source of Evidence. Assets are collected by connectors (RMM, EDR, identity providers) and feed into Evidence records.
Alternate names observed: device, endpoint, desktop, laptop, server, workstation, node, system, machine, computer, agent, managed_device, entity
Canonical fields:
| Field | Type | Description |
|---|---|---|
device_count | number | Total count of assets |
device_type | string | desktop \| laptop \| server \| mobile \| network \| virtual |
status | string | online \| offline \| active \| missing \| decommissioned |
last_seen | datetime | Last communication timestamp |
agent_version | string | Installed agent version |
is_compliant | boolean | Whether asset passes compliance policy |
os | string | Operating system |
network_segment | string | Network segment or subnet |
external_id | string | Source-tool asset identifier |
company_id | string | MSP tenant |
client_id | string | End-client tenant |
Asset-producing connectors (production): auvik (network devices), huntress (agents), liongard (systems), ninjarmm (devices), sentinelone (agents), threatlocker (computers), msgraph (managed devices via Intune)