Pega CPSSA study materials
Pega CPSSA study resources

Pega CPSSA: Security in Pega CPSSA

Pega CPSSA · Work through your exam, one topic at a time.

All guide sections

Security in Pega CPSSA

What the domain tests

Security tests authentication, authorization, and data protection in a Pega application. Senior architects must choose access groups, roles, privileges, and attribute-based policies that enforce least privilege without breaking case work.

Core rules

  • Authentication proves identity (for example, SAML, OIDC, LDAP, or local authentication with MFA); authorization decides what that identity may do.
  • An operator has access groups; access groups carry access roles. Roles grant class-level permissions, while privileges gate specific actions such as approval or override.
  • Prefer attribute-based access control policies for row-level conditions, such as restricting claims by organization unit, over creating a role per team.
  • Enforce security server-side in flows and services; UI visibility is not authorization.
  • Protect sensitive data in transit and at rest, and limit service accounts and integrations to the minimum access needed.
  • Test negative cases: a user outside the org unit must not read the case even if they know the URL or case ID.

Worked example

Claims adjusters may view only claims in their own organization unit, and only supervisors may approve. Create an access role for claims work with read/write to the claim class, assign it through the adjusters' access group, and add an access policy condition that compares the claim's organization unit to the operator's. Gate the Approve action with a privilege granted only to the supervisor role. Reasoning: the role grants the class permissions, the policy narrows rows by attribute, and the privilege controls the sensitive action. This scales better than one role per unit and enforces the rule outside the UI.

Traps

Granting broad class access and relying on a when condition in a section is a security defect. Overusing roles for every data variation creates administration burden. Forgetting that integrations and background jobs also need constrained access groups can create privilege gaps. Not testing direct URL or API access leaves horizontal privilege escalation undetected.