Study guide
8.3 Attribute-Based Access Control (ABAC), Encryption & Audit Trails
Pegasystems Certified Pega System Architect CSA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Architecture Foundations
1.1 Certified Pega System Architect Exam Format, Blueprint & Strategy 1.2 Pega Architecture & Enterprise Class Structure (ECS) 1.3 Studio Environments: App Studio, Dev Studio, Admin Studio & Prediction Studio
2 Chapter 2: Case Lifecycle Design & Core Workflows
2.1 Case Types, Stages, Processes, and Steps 2.2 Routing Strategies: Worklists, Work Queues, and Teams 2.3 Service Level Agreements (SLAs) & Urgency Calculations
3 Chapter 3: Advanced Case Management Patterns
3.1 Multi-Step Processes, Parallel Processing & Sub-processes 3.2 Child Cases, Data Propagation & Wait Steps 3.3 Optional Actions, Approvals & Case Resolution 3.4 Duplicate Case Detection, Automation Shapes & Automated Correspondence
4 Chapter 4: Data Modeling & Data Page Architecture
4.1 Data Objects, Property Modes & Page Types 4.2 Data Pages: Scope, Types & Refresh Policies 4.3 Data Transforms & Object Mapping
5 Chapter 5: Business Logic, Calculations & Decisioning
5.1 Declare Expressions & Declarative Network Chaining 5.2 Decision Tables & Decision Trees 5.3 Integration Connectors, Systems of Record & Error Handling
6 Chapter 6: User Interface & User Experience Design
6.1 Traditional UI vs Constellation Architecture 6.2 Views, Dynamic Layouts, Design Templates & Action Sets 6.3 Form Validation, Edit Validate & WCAG Accessibility 6.4 Form Views: Default vs Hierarchical Forms, Field Groups & Primary Fields
7 Chapter 7: Rule Architecture & Rule Resolution
7.1 Rulesets, Versioning & Ruleset Stack Hierarchy 7.2 The Rule Resolution Algorithm 7.3 Circumstancing & Rule Specialization
8 Chapter 8: Security & Access Control
8.1 Authentication, Operator Records & Access Groups 8.2 Role-Based Access Control: Access Roles, ARO & Privileges 8.3 Attribute-Based Access Control (ABAC), Encryption & Audit Trails 8.4 The Security Checklist & Secure Deployment
9 Chapter 9: DevOps, Testing & Application Quality
9.1 Guardrail Compliance, Best Practices & Performance Profiling 9.2 Automated Testing: Pega Unit Test Cases & Scenario Testing 9.3 Packaging, Branching & Deployment Manager CI/CD
10 Chapter 10: Reporting & Operational Analytics
10.1 Report Definitions: Querying, Columns, Summaries & Joins 10.2 Filtering, Parameters & Column Exposure Optimization 10.3 Insights, Visual Dashboards & Business Metrics
11 Chapter 11: Mobility, Digital Channels & Portals
11.1 Mobile Channel Configuration & Offline Processing 11.2 Web Mashup, Digital Channels & Constellation Embed 11.3 Channels, Personas, Portals & Landing Pages
12 Chapter 12: Center-out Architecture, Enterprise Reuse & Agile Delivery
12.1 Center-out Business Architecture & the Case for Pega 12.2 The Situational Layer Cake, Modules & Enterprise Reuse 12.3 Agile Workbench, Workspaces, Branches, Delivery Roles & the Estimator
13 Chapter 13: Pega GenAI for System Architects
13.1 Pega Blueprint: Creating, Importing & Modifying an Application Design 13.2 Pega GenAI Autopilot & Pega GenAI Coach 13.3 Pega GenAI Connect Rules, Knowledge Buddy, Agents & Tool Rules
8.3 Attribute-Based Access Control (ABAC), Encryption & Audit Trails
Key Takeaways Explain This Topic AI
Attribute-Based Access Control (ABAC) augments RBAC by evaluating contextual user attributes, case attributes, and environmental conditions at runtime, enforcing row-level case filtering and column-level property masking.
An ABAC implementation requires pairing an Access Control Policy (Rule-Access-Policy) with an Access Control Policy Condition (Rule-Access-PolicyCondition) across Read, Update, Discover, Delete, or PropertyRead actions.
Property-level encryption encrypts sensitive PII fields (such as SSN or banking credentials) within the storage stream (BLOB) using cryptographic keystores and symmetric ciphers like AES-256.
Field-level auditing automatically tracks and timestamps modifications to critical case properties, appending immutable audit entries to pyWorkHistory in the pc_history_work database table.
In Pega's layered defense, RBAC evaluates first to determine baseline class and feature entitlements, followed by ABAC to dynamically restrict or mask matching data rows and columns.
Last updated: September 2026
8.3 Attribute-Based Access Control (ABAC), Encryption & Audit Trails
While Role-Based Access Control (RBAC) provides robust, class-level entitlements based on user personas, modern enterprise compliance requires dynamic, context-sensitive security that adapts to real-time data attributes and regulatory mandates (such as GDPR, HIPAA, and PCI-DSS).
Pega Platform meets these demands through three advanced security capabilities:
Attribute-Based Access Control (ABAC) : Dynamic row-level case filtering and column-level property masking.
Cryptographic Data Protection & Encryption : Securing sensitive personally identifiable information (PII) at rest, in memory, and within the database BLOB.
Field-Level Auditing : Immutable, forensic tracking of modifications to mission-critical case properties.
1. Evolution from RBAC to Attribute-Based Access Control (ABAC)
In traditional RBAC, access decisions depend strictly on static user roles. However, enterprise business rules often demand contextual restrictions:
"Underwriters may only view loan applications originated in their assigned geographic territory."
"Customer service representatives may see a customer's case history, but the Social Security Number must display only the last four digits unless the supervisor authorizes an unmasking."
"Physicians may only open medical claim cases where they are listed as the primary attending care provider."
Attempting to solve these requirements using RBAC results in role explosion —creating hundreds of artificial roles like Underwriter-Northeast , Underwriter-Southwest , and Manager-Tier2-California .
Attribute-Based Access Control (ABAC) solves this by evaluating four dynamic vectors at runtime:
Subject Attributes : Attributes of the authenticated operator (e.g., Operator.pyDepartment , Operator.Region , Operator.SecurityClearance ).
Resource Attributes : Attributes of the target case or data instance (e.g., Case.Region , Case.ClaimAmount , Case.SensitivityLevel ).
Action : The specific operation requested ( Read , Update , Discover , Delete , PropertyRead ).
Environmental Context : Contextual factors such as current time, client IP subnet, or device posture.
2. ABAC Policies in Pega Platform
Pega implements ABAC through two complementary rule types located in Dev Studio under the Security rule category: +-------------------------------------------------------------------------+
- | PEGA ABAC POLICY RULES |
- +-------------------------------------------------------------------------+
- | [1] ACCESS CONTROL POLICY (Rule-Access-Policy) |
- | Defines the Target Class (Applies-To), the Policy Action, and |
- | references one or more Policy Conditions. |
- | |
- | [2] ACCESS CONTROL POLICY CONDITION (Rule-Access-PolicyCondition) |
- | Defines the reusable boolean filter logic comparing Subject |
- | attributes against Resource properties. |
- +-------------------------------------------------------------------------+
- The Five ABAC Policy Actions
An Access Control Policy ( Rule-Access-Policy ) specifies the protected class and selects exactly one of five policy actions:
Policy Action Enforcement Mechanism Business Use Case & Impact
Read Injected dynamically into database queries and evaluated when opening a case. Restricts full case viewing. If condition fails, user receives an access-denied error when attempting to open the case.
Update Evaluated whenever an operator attempts to save or submit changes to a case. Restricts modification. If condition fails, the case opens in read-only mode, disabling form inputs and submission buttons.
Discover Injected into search queries, Report Definitions, and work lists. Enables limited visibility. If condition fails, the case is hidden entirely from search results and reports, preventing discovery.
Delete Evaluated prior to executing case purge or deletion routines. Restricts case deletion to instances matching specific age, status, or administrative attributes.
PropertyRead Controls property-level (column-level) field visibility and masking on forms and reports. Masks sensitive PII (e.g., SSN, Tax ID, credit card numbers, medical diagnoses) based on user clearance.
PropertyRead Masking Modes
When configuring a PropertyRead policy, architects select how the protected property appears to users who do not meet the condition criteria:
Masked (Full) : Completely replaces the data value with asterisks (e.g., ********* ).
Masked (Partial / N Characters Visible) : Reveals only designated characters, such as the last four digits of a Social Security Number or payment card (e.g., ***-**-8421 ).
Clear : The unmasked, plaintext value is displayed when the user satisfies the policy condition.
Access Control Policy Conditions ( Rule-Access-PolicyCondition )
A Policy Condition rule defines reusable conditional expressions using standard logical operators: Policy Condition Logic Expression:
(Operator.pyDepartment = Case.AssignedDepartment) AND (Case.RiskScore <= Operator.MaxAuthorizedRisk)
Because ABAC policy conditions are injected directly into the SQL generation engine for Report Definitions, case filtering occurs directly at the database tier, ensuring high query performance and preventing unauthorized records from ever entering application memory.
3. Comparison Matrix: RBAC vs. ABAC
Architectural Dimension Role-Based Access Control (RBAC) Attribute-Based Access Control (ABAC)
Primary Rule Types Rule-Access-Role-Name , Rule-Access-Role-Obj , Rule-Access-Privilege-Name Rule-Access-Policy , Rule-Access-PolicyCondition
Decision Basis Static user roles defined in the user's Access Group. Dynamic comparison of Subject, Resource, Action, and Environment attributes.
Level of Granularity Coarse-grained: Entire classes, rule types, and specific Flow Actions. Fine-grained: Specific case rows and individual property columns/fields.
Inheritance Model Inherited hierarchically via pattern and directed class inheritance. Policies defined on ancestor classes automatically apply to all child classes.
Data Masking Support No native field masking (all-or-nothing form access). Native column-level masking (Full, Partial, Clear).
Evaluation Timing Checked upfront during portal load, case open, and action rendering. Dynamically injected into SQL generation and evaluated on property fetch.
Operational Relationship Outer Gatekeeper : Evaluated first. If RBAC denies access, ABAC is never reached. Inner Filter : Evaluated second. Refines and filters data that passes RBAC.
Critical Exam Rule : ABAC does not replace RBAC. They work in tandem as a layered defense. A user must first possess valid RBAC permissions (ARO and Privileges) to access a case class before ABAC policies evaluate to filter rows or mask sensitive fields.
4. Cryptographic Data Protection & Encryption
Enterprise applications handling confidential data must comply with data-at-rest encryption standards. Pega Platform differentiates between infrastructure-level database encryption and application-level cryptographic protection. +-------------------------------------------------------------------------+
- | PEGA LAYERED ENCRYPTION ARCHITECTURE |
- +-------------------------------------------------------------------------+
- | [1] INFRASTRUCTURE LAYER: Transparent Data Encryption (TDE) |
- | Storage-tier encryption protecting physical disk drives and SANs |
- | |
- | [2] PEGA PLATFORM LAYER: Class / Table-Level Encryption |
- | Encrypts entire storage streams (BLOBs) for specific work classes |
- | |
- | [3] PROPERTY-LEVEL ENCRYPTION: Granular PII Protection |
- | Encrypts individual sensitive fields (SSN, Card Number) before |
- | persisting into the BLOB or relational database columns |
- +-------------------------------------------------------------------------+
- Infrastructure TDE vs. Application-Level Encryption
Transparent Data Encryption (TDE) : Operates at the relational database management system (RDBMS) or storage hardware layer. Protects against physical disk theft or raw backup tampering, but provides zero protection if an unauthorized user gains access through an authenticated database session.
Pega Application-Level Encryption : Operates inside the Pega engine before data is persisted. Encrypts data in application memory and writes cipher-text directly into the database Storage Stream ( pzPVStream BLOB) or relational columns. Even database administrators inspecting tables directly see only encrypted binary strings.
Property-Level Encryption Configuration
To protect sensitive individual fields (such as .TaxIdentifier , .CreditCardNumber , or .HealthRecordID ):
In Dev Studio, open the property rule ( Rule-Obj-Property ).
On the Advanced tab, select the Encrypt control checkbox.
Once marked, the Pega engine automatically encrypts the property using the configured enterprise Keystore before writing to the database, and decrypts the property transparently when loaded into authorized clipboard sessions.
Keystores and Key Management Systems (KMS)
Pega manages cryptographic keys using Keystore data instances ( Data-Admin-Security-Keystore ):
Supports standard formats including Java Keystore (JKS) and PKCS12 .
Integrates natively with cloud Key Management Services, including AWS KMS , Microsoft Azure Key Vault , Google Cloud KMS , and HashiCorp Vault .
Employs AES-256 symmetric cipher suites with master key rotation policies to ensure cryptographic longevity and regulatory compliance.
5. Field-Level Auditing and Immutable Case History
Regulatory compliance mandates that modifications to critical financial, personal, or legal case data maintain an immutable, non-repudiable audit trail .
The Case History Architecture
Every case instance maintains a corresponding history log stored in the dedicated history database table pc_history_work (mapped to classes derived from History-Work- ).
Whenever a user progresses a case, executes an assignment, or updates status, the engine appends a record to the Page List property .pyWorkHistory .
Standard audit history captures:
Timestamp ( pxTimeCreated ) : Exact date and time of the event.
Actor ( pyPerformer ) : The Operator ID who performed the change.
Action Description ( pyMessageKey ) : Description of the lifecycle event or stage transition.
Configuring Field-Level Auditing
Standard case history records high-level workflow events, but does not track individual property modifications by default. Architects configure Field-Level Auditing to track changes to critical properties (such as .LoanAmount , .InterestRate , or .BeneficiaryName ):
App Studio Configuration : Navigate to Case Type Settings > Auditing . Enable auditing and select the specific fields to monitor.
Dev Studio Configuration : Utilize the Field-Level Auditing wizard or configure a Declare Trigger ( Rule-Declare-Trigger ) running on the class that monitors .pyWorkPage changes and calls standard history logging activities.
Audit Detail Captured : When an audited property changes, the system records:
The property name.
The previous value (Old Value).
The new updated value (New Value).
The modifying operator and timestamp.
Immutability and Compliance Integrity
Audit records stored in pc_history_work are strictly immutable :
Standard Pega application rules and user portals provide no mechanism to edit or delete history rows.
Modifications trigger automatic checksum updates.
This non-repudiation architecture guarantees compliance with external audit standards, including Sarbanes-Oxley (SOX) , HIPAA Security Rule , and PCI-DSS Requirement 10 .
6. Enterprise Compliance Best Practices & Exam Pitfalls
Common Architecture Mistake Regulatory / Operational Risk Certified Architect Solution
Exposing encrypted properties without ABAC masking If an unmasked property is exposed in a Report Definition, unauthorized users can view raw confidential PII. Combine property encryption with a PropertyRead ABAC policy to enforce partial or full masking in UI views.
Attempting to replace RBAC entirely with ABAC Eliminating ARO rules removes class-level guardrails, allowing unintended access if an ABAC policy condition is misconfigured. Always maintain a strict baseline RBAC structure (AROs and Privileges); apply ABAC as an additive filtering layer.
Over-auditing high-frequency transactional fields Enabling field-level auditing on dozens of frequently updated calculation properties causes massive database table bloat in pc_history_work . Audit only legally binding, financial, or compliance-critical properties that require forensic traceability.
Hardcoding cryptographic keys in application rules Hardcoded keys in properties or data transforms violate security standards and prevent automated key rotation. Store cryptographic materials in enterprise Keystores ( Data-Admin-Security-Keystore ) linked to cloud KMS vaults.