Skip to main content

Compliance data model

In the process of developing integrations for Governance, Risk, and Compliance (GRC) products, our fundamental approach begins with a comprehensive reference model, such as the one presented here. The primary objective is to systematically capture various entities and establish their interrelationships, enabling customers utilizing GRC products to employ consistent queries across any GRC product seamlessly integrated with JupiterOne. As each product may differ in terms of features and import capabilities into JupiterOne, specific adjustments are made, ensuring a bespoke and optimized integration for each unique GRC offering.

Standards, Sections, and Requirements​

Standards​

A standard is a collection of requirements grouped by sections, or a collection of controls grouped by domains. Standards are, broadly, compliance frameworks, regulations, or industry best practices. Standards can be used interchangeably with the synonymous term frameworks.

Examples of standards include: HIPAA, ISO 27001, PCI-DSS, FedRAMP, NIST CSF, CIS Benchmarks, etc.

Sections​

Sections can be considered as parts or components of a standard. While a standard has one or more sections, a section has one or more requirements.

Examples of sections include: HIPAA Physical Safeguards (§164.310), ISO 27001 Clause 6, PCI-DSS Requirement 8, the Access Control (AC) Family within FedRAMP, CIS Basics 2. Inventory of Software Assets, etc.

Requirements​

Requirements comprise sections of a standard. Individual requirements outline the specification that needs to be met.

When thinking through different regulatory or compliance standards/frameworks, the idea of a standard having one or more sections, which have one or more requirements is equivalent to a framework having one or more domains, which have one or more controls.

Examples of requirements include: HIPAA §164.310(a)(1)(i), ISO 27001 6.1.3 a, PCI-DSS 8.4.b, FedRAMP AC-2 (7), utilizing application whitelisting to implement CIS Basics 2.7, etc..

Policies, Procedures, and Controls​

You can think of an organization’s policies, procedures, and controls to loosely align to the compliance or regulatory standards, sections, and requirements.

Another way of looking at it would be: policies + procedures reflect your organization's internal view of how to run security, which is demonstrated to external stakeholders via the compliance implementation of standards/sections/requirements, or framework/domains/controls.

At JupiterOne, we have an internal framework of controls. Our security operation is reflected in our policies + procedures within the Policies app. Policies map to domains, procedures map to controls. Conversely, those same internal JupiterOne policies, procedures, and controls satisfy external regulatory/compliance standards, sections, and requirements in the Compliance app.

Policies​

Policies are high-level statements of management intent; they are written security documents which frequently satisfy external requirements. Policies are implemented by procedures.

Examples of policies include: access management policies, data protection policies, human resource policies.

Procedures​

Procedures are written security documents which describe how to implement policies via technology or processes, or a combination of the two; the ‘who’, ‘what’, ‘when’, ‘how’, etc; they can be thought of as control or process descriptions.

Examples of procedures (aka control/process descriptions) include: password management, protecting data at rest, employee screening

Policies are implemented by procedures, while controls implement procedures.

Controls​

Controls are the technical, administrative, and physical safeguards that enforce the procedures; they can manifest commonly as a process managed by a person/team or as a product/service provided by a vendor.

Examples of controls include:

user identity management, access control, multi-factor authentication data encryption at rest or in transit, penetration testing, code scanning, pre-employment background checks.

ControlPolicy​

A ControlPolicy or Configuration enforces or manages a Control.

Control Policies or configurations are the technical settings whereby controls are implemented.

Examples of control policies or configurations include:

  • Requiring 12+ characters including a number + a symbol for all passwords
  • Using AES-256 cipher for encryption at rest
  • For background checks, specifically include searches for federal criminal, state, county, city, financial, and education verification
  • Vendors provide controls

Policies are implemented by procedures; controls implement procedures. A Control Policy or configuration enforces or manages a control.

Vendors​

Vendors are frequently companies, organizations, or people that provide the controls.

Examples of vendors include:

  • Microsoft (the Vendor) for Active Directory (AD), user authentication, and access control
  • Amazon Web Services (AWS, the Vendor) for Key Management Service (KMS)
  • Checkr (the Vendor) for background screens

Policies are implemented by procedures; controls implement procedures. Vendors provide controls.

Contents