title: Violation Remediation category: Policies tags: violations, remediation, automation, actions, workflow priority: Normal
Violation Remediation
When policies detect issues in your environment, violations are created. This article covers how to view, manage, and remediate violations in IdentityCenter -- from manual investigation through fully automated responses.
Violation Management
Accessing Violations
Navigate to Governance > Policies, then click any policy to see its violations at /admin/compliance/policies/{id}/violations. You can also view all violations across all policies from Governance > All Violations.
Violation List View
The violations page displays all detected issues for the selected policy:
| Column | Description |
|---|---|
| Object | The user, group, or computer that triggered the violation (clickable link to the detail page) |
| Policy | Which policy was violated |
| Severity | Critical, High, Medium, Low, or Info |
| Status | Open, Acknowledged, Remediated, Closed, or Ignored |
| Detected | When the violation was first detected |
| Last Evaluated | When the policy last confirmed the violation still exists |
Violation Statistics
At the top of the violations page, summary statistics provide a quick health check:
| Statistic | Description |
|---|---|
| Open Count | Total violations in Open status |
| Critical Count | Violations with Critical severity |
| High Priority Count | Violations with High severity |
| Resolved Count | Violations resolved in the current period |
| Trend | Whether violations are increasing or decreasing over time |
Violation Statuses
Each violation moves through a lifecycle:
| Status | Meaning | How It Gets Here |
|---|---|---|
| Open | Newly detected, needs attention | Automatically set when the policy evaluation finds a match |
| Acknowledged | Someone is aware and investigating | Manually set by an administrator |
| Remediated | Corrective action has been taken | Set when an automated or manual action is completed |
| Closed | The violation no longer exists | Automatically set when the next policy evaluation no longer detects the condition |
| Ignored | Intentionally accepted as a known risk | Manually set with a required justification comment |
Status Transitions
Open --> Acknowledged --> Remediated --> Closed
| ^
| |
└--> Ignored (auto-closed when condition clears)
Violations in Remediated status are automatically moved to Closed when the next policy evaluation confirms the condition no longer exists. If the condition recurs, a new violation is created.
Manual Remediation
Investigating a Violation
- Click the violation to open its detail view
- Review the violation context:
- Which object is affected
- What condition was detected
- When it was first and last detected
- Severity level and policy description
- Click the object link to navigate to the full detail page for additional context
Taking Manual Action
From the violation detail view, you can take direct action:
| Action | Description |
|---|---|
| Disable Account | Disable the user or computer account in AD (immediate write-back) |
| Remove from Group | Remove the object from a specific group in AD |
| Set Manager | Assign a manager to resolve "Unresolved Manager" violations |
| Edit Attributes | Update any writable attribute (department, title, etc.) |
| Mark as Acknowledged | Indicate you are aware and investigating |
| Mark as Ignored | Accept the risk with a justification comment |
After taking an action, update the violation status to Remediated. The next policy evaluation will confirm whether the condition is resolved and move the violation to Closed automatically.
The ViolationAction Component
The ViolationAction.razor component provides the UI for taking action on individual violations. It displays the available actions based on the violation type and the current user's permissions, and it confirms each action before execution.
Automated Remediation Actions
When configuring a policy, you can assign automated actions that execute immediately when a violation is detected.
Available Automated Actions
| Action | What It Does | Risk Level |
|---|---|---|
| Log Only | Records the violation in the database. No external action is taken. | None |
| Send Alert | Sends an email notification to designated recipients (the user's manager, a security team distribution list, or a specific address). | None |
| Create Ticket | Creates a ticket in your connected ITSM system (ServiceNow or Jira) with the violation details. | None |
| Disable Account | Disables the AD account via write-back. The user immediately loses the ability to log in. | High |
| Flag for Review | Adds the affected user's access to the next access review campaign for a reviewer to evaluate. | Low |
| Remove from Group | Removes the user from the offending group via AD write-back. | Medium |
| Force Password Reset | Sets the "User must change password at next logon" flag in AD. | Low |
Combining Actions
You can configure multiple actions for a single policy. They execute in sequence:
Example: Stale Admin Account Policy
1. Log Only (always)
2. Send Alert to security-team@company.com
3. Create Ticket in ServiceNow (Priority: High)
4. Disable Account (after 14-day grace period)
The RemediationService
The RemediationService is the backend service that executes automated remediation actions. It:
- Receives violation details from the policy evaluation engine
- Determines which actions to execute based on the policy configuration
- Calls the appropriate service for each action (email service, ticketing API, write-back service)
- Logs the result of each action in the audit trail
- Updates the violation status to Remediated on success
AD Write-Back for Remediation
High-impact actions like Disable Account, Remove from Group, and Force Password Reset use the IObjectWriteBackService to make changes directly in Active Directory.
How Write-Back Works
- The
RemediationServicecallsIObjectWriteBackServicewith the requested change - The
ObjectWriteBackServiceimplementation connects to AD using the configured service account credentials - The change is applied in AD via LDAP
- A
ChangeAuditLogentry is created recording who/what initiated the change, the old value, and the new value - The violation is updated to Remediated status
Audit Trail
Every write-back action creates a complete audit record:
| Audit Field | Description |
|---|---|
| Timestamp | When the action was executed |
| Initiated By | The policy name and action type (e.g., "Policy: Stale User Accounts / Action: Disable Account") |
| Object | The affected AD object |
| Change Type | What was changed (account status, group membership, attribute value) |
| Old Value | The previous value |
| New Value | The new value |
| Source | "Automated Remediation" or the administrator's username for manual actions |
Write-Back Caller Context
For automated remediation actions that run without an HTTP context (background jobs, scheduled policy evaluations), the system uses WriteBackCallerContext.System("PolicyRemediation") to identify the source in audit logs.
Approval Workflows for Remediation
For high-impact remediation actions, you can require approval before execution.
When to Require Approval
| Action | Approval Recommended? | Rationale |
|---|---|---|
| Log Only | No | No impact |
| Send Alert | No | Informational only |
| Create Ticket | No | Creates a work item, no direct change |
| Flag for Review | No | Adds to review queue, no direct change |
| Force Password Reset | Optional | Low impact but may disrupt the user |
| Remove from Group | Yes | May revoke access the user needs |
| Disable Account | Yes | Prevents the user from working entirely |
Configuring Approval Requirements
- Edit the policy
- In the Actions section, select an action that supports approval
- Enable Require Approval
- Select the approver: the user's manager, a specific person, or a group
- Set the approval timeout (what happens if no one approves within the deadline)
When approval is required, the action is queued but not executed. The approver receives a notification and can approve or reject the action. See Workflow Designer and Approver Resolution for details on the approval workflow.
Risk Acceptance (Ignoring Violations)
Sometimes a violation represents an intentional configuration. For example, a break-glass admin account may legitimately have "Password Never Expires" set.
How to Accept Risk
- Open the violation detail view
- Click Ignore / Accept Risk
- Enter a justification comment explaining why this violation is acceptable
- Optionally set an expiration date for the acceptance (forces re-evaluation later)
- Confirm
Risk Acceptance Best Practices
| Practice | Rationale |
|---|---|
| Always require a justification | Auditors will ask why the violation was accepted |
| Set an expiration date | Circumstances change; accepted risks should be periodically re-evaluated |
| Limit who can accept risk | Only senior administrators or security team members should have this permission |
| Review accepted risks quarterly | Ensure accepted violations are still justified |
| Use policy exceptions instead for permanent cases | If the condition is always valid for certain accounts, add them as policy exceptions rather than ignoring each violation individually |
Remediation Strategy: Graduated Approach
The recommended approach for new policies is to start conservatively and increase automation over time.
Phase 1: Observe (Weeks 1-2)
| Action | Purpose |
|---|---|
| Log Only | Understand the scope of the issue |
| Review violations manually | Verify there are no false positives |
| Tune policy conditions | Adjust thresholds and add exceptions |
Phase 2: Alert (Weeks 3-4)
| Action | Purpose |
|---|---|
| Send Alert | Notify responsible parties |
| Monitor response rates | Determine if alerts are being acted on |
| Refine recipient lists | Ensure the right people are notified |
Phase 3: Automate (Week 5+)
| Action | Purpose |
|---|---|
| Disable Account or Remove from Group | Automated remediation with approval workflows |
| Monitor audit logs | Verify actions are executing correctly |
| Track resolution times | Measure improvement from automation |
Important: Never jump directly to automated account disabling for a new policy. False positives in a "Disable Account" action can lock out legitimate users and cause business disruption.
Next Steps
- Policies Overview -- Understand the policy framework
- Built-In Policies Reference -- Complete list of pre-configured policies
- Creating Policies -- Build custom policies
- Lifecycle Management -- Automate identity lifecycle actions
- Object Write-Back -- How AD changes are made
- Workflow Designer -- Configure approval workflows for remediation
- Access Reviews -- Use "Flag for Review" to route violations into access reviews
- AI Chat -- Ask questions about violations in natural language