, it governs access permissions, audit behavior, script integrity requirements, and other operational controls that protect SortCL-compatible jobs in production.<\/span><\/p>\nIntroduced with CoSort Version 11, the IRI OGS Policy File serves as the central governance authority for SortCL-compatible jobs across the IRI data management platform.\u00a0<\/span><\/p>\nThe Runtime Governance Challenge<\/b><\/h2>\n
Many organizations manage sensitive data across multiple applications, environments, and business units. Security teams may define access policies, but enforcing those policies consistently across operational data jobs can prove difficult.<\/span><\/p>\n![\"Runtime](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/06\/runtime-governance-challenge-1024x683.png\")
<\/p>\n
Without centralized governance, organizations often face several challenges. For example:<\/p>\n
\n- Inconsistent permissions across jobs and environments<\/span><\/li>\n
- Limited visibility into who accessed sensitive information<\/span><\/li>\n
- Unauthorized script modifications<\/span><\/li>\n
- Weak audit trails<\/span><\/li>\n
- Difficult compliance reporting<\/span><\/li>\n
- Configuration drift between development, test, and production systems<\/span><\/li>\n<\/ul>\n
These challenges become even more significant when processing regulated data such as personally identifiable information (PII), protected health information (PHI), controlled unclassified information (CUI), financial records, or other sensitive business data.<\/span><\/p>\nTraditional application security controls do not always govern what happens during data processing. A user who can execute a job may gain access to data elements that should remain restricted. A modified script may run without validation. Critical audit information may never be captured.<\/span><\/p>\nTherefore, organizations need governance controls that operate directly within the data processing layer.<\/p>\n
How the IRI OGS Policy File Enables Runtime Governance<\/b><\/h2>\n
The IRI OGS Policy File serves as the governance backbone of OGS, providing centralized role-based access control (RBAC), audit logging, script integrity enforcement, and other runtime governance controls for SortCL-compatible jobs. The OGS documentation describes it as:<\/span><\/p>\n“The policy definitions and permission controls\u2026 an application-independent RBAC and logging control center.”<\/span><\/p>\nThe Policy File stores governance rules in an encrypted JSON format that administrators can create, view, and modify only through the Policy File Manager (PFM). It <\/span>governs four primary categories:<\/span><\/p>\n\n\n\nCategory<\/strong><\/span><\/td>\nDescription<\/strong><\/span><\/td>\n<\/tr>\n<\/thead>\n\n\n| Users<\/td>\n | Individual login identities<\/td>\n<\/tr>\n | \n| Groups<\/td>\n | Collections of users who share common responsibilities<\/td>\n<\/tr>\n | \n| Roles<\/td>\n | Purpose-built collections of users and groups that simplify permission management<\/td>\n<\/tr>\n | \n| Forms<\/td>\n | Files, fields, tables, URLs, functions, conditions, scripts, sets, and other governed assets<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n In addition, the Policy File controls:<\/p>\n \n- Error verbosity<\/span><\/li>\n
- Ungoverned behavior settings<\/span><\/li>\n
- Audit log content<\/span><\/li>\n
- Audit log retention<\/span><\/li>\n
- Script signature requirements<\/span><\/li>\n
- Metadata descriptions<\/span><\/li>\n<\/ul>\n
By centralizing governance controls in one encrypted location, organizations create a single source of truth for operational security policies.<\/span><\/p>\nKey Benefits<\/b><\/h3>\n![\"Infographic](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/06\/Key-benefit-OGS-1024x541.png\") <\/h4>\n1. Enforced Role-Based Access Control<\/b><\/h4>\n
The primary purpose of the Policy File is to define permissions for governed assets.<\/span><\/p>\nAdministrators can assign read, write, or execution permissions to users, groups, and roles. These permissions apply directly to files, fields, scripts, functions, and other runtime objects.<\/span><\/p>\nThis approach helps organizations implement least-privilege security while reducing the risk of unauthorized access.<\/span><\/p>\n2. Centralized Governance Management<\/b><\/h4>\nThe Policy File stores governance settings in a single encrypted repository. Security teams can manage permissions, audit requirements, and retention policies without maintaining separate configurations across multiple jobs.<\/span><\/p>\n3. Optional Script Integrity Validation<\/b><\/h4>\nOrganizations can require SortCL scripts to contain valid cryptographic signatures before execution.<\/span><\/p>\nWhen signature validation is enabled, OGS verifies script integrity before processing begins. Modified or unsigned scripts can be prevented from running.<\/span><\/p>\nThis capability helps reduce the risk of unauthorized job modifications.<\/span><\/p>\n4. Granular Audit Logging<\/b><\/h4>\nThe Policy File also determines what information SortCL records during execution.
\n<\/span>These audit records support:<\/span><\/p>\n\n- Compliance validation<\/span><\/li>\n
- Security investigations<\/span><\/li>\n
- Data lineage analysis<\/span><\/li>\n
- Operational troubleshooting<\/span><\/li>\n
- Performance monitoring<\/span><\/li>\n<\/ul>\n
Even unsuccessful job executions can generate audit records, helping organizations maintain complete operational visibility.<\/span><\/p>\n5. Lightweight Data Cataloging<\/b><\/h4>\nOptional descriptions allow administrators to document governed assets.
\n<\/span>Organizations can record business context for:<\/span><\/p>\n\n- Files<\/span><\/li>\n
- Fields<\/span><\/li>\n
- Functions<\/span><\/li>\n
- Classes<\/span><\/li>\n
- Users<\/span><\/li>\n
- Groups<\/span><\/li>\n
- Roles<\/span><\/li>\n<\/ul>\n
This capability creates a lightweight metadata repository that supports governance and data discovery initiatives.<\/span><\/p>\nHow the Policy File Works During Runtime<\/b><\/h2>\nWhen a SortCL job executes, OGS performs a series of governance checks before allowing the process to continue.
\n<\/span>The sequence typically includes:<\/span><\/p>\n\n- Reading the job script and metadata<\/span><\/li>\n
- Loading and decrypting the Policy File<\/span><\/li>\n
- Loading matching sub-policy file (if any)<\/span><\/li>\n
- Validating script signatures (if required)<\/span><\/li>\n
- Comparing the logged-in user against RBAC rules<\/span><\/li>\n
- Allowing or denying execution<\/span><\/li>\n
- Writing a JSON audit log<\/span><\/li>\n<\/ol>\n
The OGS documentation summarizes this process as follows:
\n<\/span>“SortCL compares the logged-in user against Policy file RBACs\u2026 then gives a go\/no-go signal to run the script.”<\/span><\/p>\nThis workflow ensures that governance decisions occur before sensitive data processing begins.<\/span><\/p>\n![\"IRI](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/06\/How-the-IRI-OGS-policy-works-1024x386.png\") <\/p>\n
IRI OGS Policy File runtime governance workflow showing SortCL job execution, policy file decryption, sub-policy loading, script signature validation, RBAC authorization checks, allow-or-deny decisions, and JSON audit log generation.<\/p>\n Practical Example: Policy File Syntax<\/b><\/h2>\nThe Policy File uses a JSON structure to define governance rules.
\n<\/span>The example below demonstrates how administrators can restrict access to both files and fields:<\/span><\/p>\n\"FORMS\"<\/span>: {<\/span>\r\n \u00a0<\/span>\"FILES\"<\/span>: {<\/span>\r\n \u00a0\u00a0\u00a0<\/span>\"INSTANCES\"<\/span>: [<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0{<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\"NAME\"<\/span>: <\/span>\"TRANSACTIONS.dat\"<\/span>,<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\"READERS\"<\/span>: [<\/span>\"Legal\"<\/span>, <\/span>\"IT\"<\/span>],<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\"WRITERS\"<\/span>: [<\/span>\"Legal\"<\/span>, <\/span>\"IT\"<\/span>],<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\"Comment\"<\/span>: <\/span>\"This data file contains medical information.\"<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0<\/span>}<\/span>\r\n \u00a0\u00a0\u00a0]<\/span>\r\n \u00a0},<\/span>\r\n \u00a0<\/span>\"FIELDS\"<\/span>: {<\/span>\r\n \u00a0\u00a0\u00a0<\/span>\"INSTANCES\"<\/span>: [<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0{<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\"NAME\"<\/span>: <\/span>\"SSN\"<\/span>,<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\"READERS\"<\/span>: [<\/span>\"SSN_READER\"<\/span>],<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\"WRITERS\"<\/span>: [<\/span>\"SSN_READER\"<\/span>],<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\"Comment\"<\/span>: <\/span>\"Sensitive identifier; access restricted.\"<\/span>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0<\/span>}<\/span>\r\n \u00a0\u00a0\u00a0]<\/span>\r\n \u00a0}<\/span>\r\n}<\/span><\/pre>\nIn this example, only the Legal and IT groups can read or modify the file <\/span>TRANSACTIONS.dat<\/span>, while only the <\/span>SSN_READER<\/span> role can access the SSN field.<\/span><\/p>\nEven within a shared processing environment, governance controls remain highly granular and can help enforce strict need-to-know access policies.<\/span><\/p>\nManaging Exceptions with Sub-Policy Files<\/b><\/h2>\nSub-policy files allow administrators to override global permissions for a specific SortCL job without modifying the primary governance policy.<\/span><\/p>\nSub-policy files follow the naming convention:<\/span><\/p>\n<jobname>.scl.ctl<\/code><\/p>\nAccording to the OGS documentation:<\/span><\/p>\n\u00a0 \u00a0 \u00a0 \u00a0 “A sub-policy file overrides all items in the FORMS section of the main Policy file.”<\/span><\/p>\nThis capability helps organizations manage job-specific exceptions while keeping the global Policy File clean and maintainable.<\/span><\/p>\nExample Use Case<\/b><\/h3>\nSuppose the global Policy File restricts access to the field <\/span>rank<\/b> to members of the Executive role. However, a specific job named <\/span>bonus.scl<\/b> requires an additional user, <\/span>susang<\/b>, to access that field.<\/span><\/p>\nRather than changing the global policy, administrators can create a sub-policy file for the job and add:<\/span><\/p>\n\"READERS\"<\/span>: [<\/span>\"Executive\"<\/span>, <\/span>\"susang\"<\/span>]<\/span>\r\n\"WRITERS\"<\/span>: [<\/span>\"Executive\"<\/span>, <\/span>\"susang\"<\/span>
| | |