A policy governing security practices
A security policy is the written, sanctioned statement of how an organisation protects its information: the rules that decide what is allowed, what is forbidden, and who is accountable. It sits one level above the machinery. A policy says "access to production data must be authorised and logged"; the control is the thing that enforces it. The interesting tension is that a policy carries no protection by itself. It is a promise the organisation makes, and its worth depends entirely on whether the controls beneath it keep that promise.
The discipline of a formal, top-level security policy was codified by ISO/IEC 27001, the international standard for an Information Security Management System (ISMS). The standard requires top management to establish a documented information security policy that sets direction and is reviewed at planned intervals, with Annex A enumerating the controls an organisation selects to support it. The 2022 revision reorganised those controls into 93 entries across four themesThemeProduct SpecificationA strategic grouping of related featuresView reference →, which sharpened the line between the policy that states intent and the controls that realise it.
The American lineage runs through NIST. The NIST Cybersecurity Framework organises security around five functions, Identify, Protect, Detect, Respond, and Recover, and unlike ISO 27001 it offers no certificationCertificationCustomer EducationA certification programView reference →; it guides rather than certifies. Many organisations now run both, using the framework to gauge maturity and the standard to formalise and certify the management system (OneTrust).
Practice has converged on a layered document set: a short governing policy, supporting standards that fix specific parameters such as minimum key lengths, and procedures that say how to carry the work out. The policy changes rarely. The standards and procedures beneath it move as technology does.
A fintech preparing for certification writes a policy clause: "All access to systems holding customer financial data must be role-based, multi-factor, and logged." That single sentence cascades. It mandates an access control that enforces least privilege, an MFA control on every relevant login, and an audit logging control that records each access event. When the certification auditor arrives, they read the policy first, then ask for evidenceEvidenceValidationData supporting or refuting a hypothesisView reference → that each mandated control operated. A clause with no enforcing control becomes a finding. A control with no policy behind it has no authority and can be switched off by anyone with a reason. The policy is what makes the controls non-negotiable.
In the Unified Product Graph, a security policy lives in the security region as the source of governance. The product connects to it through Productgoverned bySecurity Policyhierarchy, which makes the rule set an explicit, queryable property of the product rather than a PDF in a drawer. From there the policy radiates control: product_governed_by_security_policySecurity PolicymandatesSecurity Controlhierarchy ties each clause to the mechanism that enforces it, and security_policy_mandates_security_controlSecurity PolicydefinesAccess Policyhierarchy carves out the access rules it owns. That structure encodes the central distinction: policy mandates, controls enforce. A mandated control with no enforcing node, or a policy clause connected to nothing, shows up as a gap the graph can name.security_policy_defines_access_policy
Type-specific fields on BaseNode
scopestringSystems or processes covered
review_cadencestringReview cadence (e.g. "annually", "quarterly")
versionstringVersion
effective_datestringISO effective date
urlstringPolicy document URL
policy_statusstringLifecycle status
rule_strengthstringImperative force
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
5 phases — initial: proposed · template: APPROVAL
8 edge types connected to this entity.
product_governed_by_security_policysecurity_policy_mandates_security_controlsecurity_policy_defines_access_policysecurity_policy_establishes_data_classificationsecurity_policy_requires_threat_modelsecurity_policy_schedules_security_reviewsecurity_policy_governs_incidentai_guardrail_enforces_security_policy