Policy Assignments

Policy Assignments: Linking Compliance Rules to Network Devices in rConfig V8 Pro

Policy Assignments connect policy definitions to device scopes, creating the link between compliance rules and the devices they evaluate. An assignment specifies which devices to validate (scope), which command output to evaluate (configuration source), and which policy definition to apply (compliance rules). Assignments are the operational layer that transforms abstract policy definitions into concrete compliance validation across your network infrastructure.

Understanding how to configure policy assignments correctly ensures compliance checks target the right devices, evaluate the appropriate configurations, and produce meaningful results for remediation and reporting.

New in V8.2.1

Policy Assignments gained four changes in V8.2.1: Smart Groups are now a fourth scope type (alongside Device, Tag, Category); a new Run on backup toggle automatically evaluates the assignment for any in-scope device after a successful backup; the create / edit dialog uses a single-row Type / Target / Command picker with a footer How this works popover; and the assignments list page has a View Smart Groups header button. See the Smart Groups page for the underlying primitive and Device Compliance for the per-device tab fed by post-backup runs.

Understanding Policy Assignments

What Policy Assignments Do

Link policies to devices: Assignments bridge the gap between policy definitions (rules) and device populations (targets), enabling flexible compliance enforcement across any organizational structure.

Define validation scope: Specify exactly which devices are evaluated—individual devices for granular control, categories for device type grouping, or tags for flexible cross-cutting concerns.

Select configuration source: Choose which command output to validate (e.g., show running-config, show version), ensuring policy rules evaluate relevant configuration data.

Enable selective enforcement: Disable assignments for testing or temporary suspension without deleting configuration, preserving assignment history and simplifying re-activation.

Support multiple policies: A single device can be subject to multiple policy assignments, each validating different aspects of configuration (security baseline, service standards, interface requirements).

Why Assignments Matter

Organizational flexibility: Different device types, locations, or functions require different compliance policies. Assignments enable this flexibility by allowing varied policy application based on device characteristics.

Scalable enforcement: Apply policies to hundreds or thousands of devices through category or tag assignments without configuring individual devices. As network grows, new devices automatically inherit policies based on their category or tag membership.

Testing and validation: Disabled assignments allow testing new policies against device populations without affecting compliance reports, enabling safe policy development workflows.

Audit trails: Assignment history tracks which policies applied to which devices and when, supporting compliance audits and troubleshooting historical compliance issues.

Granular control: Combine multiple assignments to validate different configuration aspects—one for security baseline, another for service standards, a third for interface configurations—providing comprehensive yet organized compliance validation.

Accessing Policy Assignments

Navigate to Compliance → Policy Assignments to access the assignment management interface.

Policy Assignments Main View

Main view displays:

• Assignment name and description
• Scope type (Device, Category, Tag) and scope name
• Command output being evaluated
• Policy definition being applied
• Enabled/disabled status
• Last execution timestamp
• Actions: View, Edit, Delete

Expandable details: Click the expand icon next to any assignment to view:

• Complete assignment configuration
• Link to view policy definition code
• Link to view compliance results
• Quick access to edit assignment

Policy Assignment Expanded View

From V8.2.1 the page header includes a View Smart Groups button (indigo gradient) that links to the Smart Groups management page, alongside an inline help popover. Use it when you need to inspect or edit the underlying Smart Group an assignment targets.

View Smart Groups header button (V8.2.1+)

Assignment Configuration Rules

Before creating assignments, understand the rules governing assignment configuration:

Rule 1: Single scope per assignment

• Each assignment can target ONE device, ONE category, OR ONE tag
• Cannot assign to multiple scopes simultaneously (e.g., cannot select “Device A AND Category B”)
• Create separate assignments for different scopes, even if using same policy definition

Rule 2: Single command per assignment

• Each assignment evaluates one command output per device
• To validate multiple commands, create separate assignments
• Choose command that contains configurations being validated by policy

Rule 3: Single policy definition per assignment

• Each assignment applies one policy definition
• Policy definition can contain multiple rules, but assignment references single definition
• To apply multiple policy definitions to same scope, create multiple assignments

Rule 4: Reusability

• Multiple assignments can use the same policy definition
• Policy definition updates automatically apply to all assignments using that definition
• Single policy can enforce compliance across varied scopes (different categories, tags, devices)

Rule 5: Enabled/Disabled state

• Assignments can be disabled without deletion
• Disabled assignments don’t execute in compliance jobs
• Useful for testing, troubleshooting, or temporary suspension

Creating a Policy Assignment

Step 1: Add New Assignment

Click New Policy Assignment to create an assignment.

VIDEOPLACEHOLDER

Step 2: Configure Assignment Name and Description

Assignment Name: Descriptive identifier indicating scope, policy, and purpose.

Naming best practices:

• Include scope type and name: Routers-Security-Baseline
• Indicate policy focus: Core-Switches-NTP-Standard
• Use consistent naming conventions: [Scope]-[PolicyArea]-[Purpose]

Description (optional): Detailed explanation of assignment purpose, why it exists, and any special considerations.

Good naming examples:

• Production-Routers-Security-Baseline
• DMZ-Firewalls-PCI-DSS-Requirements
• Access-Switches-Interface-Standards
• All-Devices-NTP-DNS-Configuration

Poor naming examples:

• Assignment1
• Test
• Policy-Check

Step 3: Select Scope

Choose assignment scope type and specific target.

Scope options:

Device: Single device compliance validation

• Use for: Unique device requirements, testing new policies, troubleshooting specific devices
• Select: Individual device from dropdown
• Example: Critical core router requiring enhanced security validation

Category: All devices in category

• Use for: Device type-specific policies (routers, switches, firewalls), role-based compliance (core, distribution, access)
• Select: Category from dropdown (e.g., “Cisco-Routers”, “HP-Switches”)
• Example: All Cisco routers must meet IOS security baseline

Tag: All devices with specific tag

• Use for: Cross-cutting policies (production vs. lab, PCI scope, geographic location), flexible grouping beyond device type
• Select: Tag from dropdown (e.g., “Production”, “PCI-Scope”, “DataCenter-A”)
• Example: All production devices require standard NTP/DNS configuration

Smart Groups (V8.2.1+): All devices currently matching a saved Smart Group rule set

• Use for: Dynamic populations that change as devices are added, retired, or relabelled (e.g., “all Cisco IOS routers running version 15.x”, “all devices imported from Netbox tagged production”)
• Select: Smart Group from dropdown
• Example: A Smart Group named Edge-Routers-IOS-15 automatically picks up new edge routers as they are imported, without you editing the assignment

Assignment Scope Selection

The V8.2.1 scope picker uses a single-row layout: pick the Type, then the Target, then the Command. The Command list is filtered by the target’s Command Group so you can only pick commands that exist for that scope.

Smart Groups scope with the homogeneity caveat (V8.2.1+)

Smart Group homogeneity

When the scope type is Smart Groups, the available commands are derived from the first matching device’s Command Group. If your Smart Group resolves to devices in different Command Groups, devices outside that first group will silently produce no compliance result for the chosen command. Either keep the Smart Group homogeneous (one Command Group), or split into multiple assignments.

Tip

Use categories for device type-based policies and tags for cross-cutting concerns. Use Smart Groups when membership needs to change automatically based on device attributes (vendor, model, status, custom properties) rather than being maintained by hand. For example, category “Cisco-Routers” for IOS-specific compliance, tag “Production” for production-only requirements that span device types, Smart Group Edge-IOS-15 for the rolling set of edge IOS devices on version 15.

Step 4: Select Command Output

Choose which command output to evaluate against policy rules.

Command selection guidelines:

Match policy to command: Choose command whose output contains configurations validated by policy definition.

• Validating NTP servers? Use show running-config
• Validating software version? Use show version
• Validating interface status? Use show ip interface brief

Avoid mismatches: Don’t select show version to validate SNMP configuration—those configs don’t appear in version output.

Consider output size: Smaller, targeted command outputs process faster than large dumps like show tech-support.

Verify command execution: Ensure selected command exists in device command groups and executes successfully during backups.

Command Selection

Common command choices:

Policy Validates	Appropriate Command
Running configuration elements	show running-config
Startup configuration	show startup-config
Software version	show version
Interface configurations	show running-config
Routing protocols	show running-config
SNMP settings	show running-config
AAA configuration	show running-config

Step 5: Select Policy Definition

Choose which policy definition contains compliance rules for this assignment.

Policy definition selection:

• Dropdown lists all available policy definitions
• Definitions display name and brief description
• Preview policy content if needed before selecting
• Can change policy definition later if requirements change

Policy Definition Selection

Selection considerations:

Policy-scope alignment: Ensure policy rules are relevant to device scope.

• Don’t assign Cisco IOS-specific policies to Juniper devices
• Don’t assign firewall policies to switches
• Match policy complexity to device capability

Command compatibility: Verify policy rules evaluate configurations present in selected command output.

• Policy checking interface configs? Command must output interface configurations
• Policy validating SNMP? Command must include SNMP configuration

Testing first: For new or modified policies, consider testing on small scope (single device or small category) before broad deployment.

Step 6: Set Enabled Status

Enabled: Assignment executes in compliance jobs, results appear in reports.

Disabled: Assignment exists in configuration but doesn’t execute. Results don’t appear in current compliance reports (historical results remain).

When to disable:

• Testing new policy definitions without affecting production reports
• Troubleshooting policy issues on specific device groups
• Temporarily suspending compliance validation during maintenance
• Preparing assignments for future activation

When to enable:

• Policy definition tested and validated
• Ready for production compliance enforcement
• Devices in scope are backing up successfully
• Command output contains required configuration data

Note

Disabling assignments is non-destructive. Historical compliance results remain accessible, and assignments can be re-enabled at any time without reconfiguration.

Step 6.5: Set Run on Backup (V8.2.1+)

The Run on backup toggle controls whether this assignment evaluates automatically after each successful device backup.

• On (default): After any device in scope finishes a successful backup, rConfig dispatches a per-device compliance check for this assignment. The result appears in the device’s Compliance tab and in the Reports list with a description starting Auto - post-backup for device …. No report email is sent for these auto runs.
• Off: The assignment only runs when triggered manually from the Policy Assignments page actions menu, by a Scheduled Task, or by clicking Re-run compliance on the device’s Compliance tab.

Run on backup toggle (V8.2.1+)

When to leave it on: most production assignments where you want continuous, low-effort compliance feedback per device.

When to turn it off:

• High-cardinality categories where every backup would dispatch dozens of compliance jobs.
• Assignments still being authored or tuned (run them manually until stable, then turn this on).
• Policies where evaluating against partial or historical configs is not useful.

Note

“Run on backup” defaults to On for newly created assignments. Existing assignments were set to On during the V8.2.1 migration. See Device Compliance for the per-device experience this feeds.

Step 7: Save Assignment

Click Save to create the assignment.

Post-creation steps:

1. Verify assignment appears in Policy Assignments list
2. Confirm scope, command, and policy definition are correct
3. If enabled, run manual compliance check to validate configuration
4. Review results and adjust if needed
5. Create Scheduled Task for automated compliance checking (optional)

How this works

The dialog footer carries a small How this works button (lower left, V8.2.1+). It opens an inline popover summarising the design constraint that drives the form’s shape: one policy definition validates the output of one specific command for the devices in one scope target. That is why each assignment binds a single Type, Target, and Command. To run the same rule across multiple Command Groups, create one assignment per group.

Managing Policy Assignments

Viewing Assignments

Main view: Lists all policy assignments with summary information and status indicators.

Expandable details: Click expand icon to view:

• Complete assignment configuration
• View Definition Code: Opens policy definition in read-only view
• View Compliance: Navigates to compliance results for this assignment
• Edit Assignment: Opens assignment editor

Editing Assignments

Click Edit to modify existing assignment.

Editable elements:

• Assignment name and description
• Scope (can change scope type or target)
• Command output selection
• Policy definition
• Enabled/disabled status

Edit considerations:

Scope changes: Changing scope (e.g., from Category A to Category B) immediately affects which devices are evaluated. Existing compliance results for old scope remain in history but new jobs evaluate new scope.

Command changes: Changing command output may cause policy failures if policy rules don’t match new command’s output format. Verify policy compatibility before changing commands.

Policy definition changes: Changing to different policy definition entirely changes compliance criteria. Consider creating new assignment instead of modifying existing one if tracking different compliance aspects.

Testing after changes: After significant edits, run manual compliance check to verify assignment works as expected before relying on scheduled execution.

Caution

Editing assignments affects compliance validation immediately. Test changes on disabled assignments or small scopes before applying to production device populations.

Viewing Policy Definition from Assignment

From expanded assignment view, click View Definition Code to see the policy definition being applied.

View capabilities:

• Read-only display of policy definition content
• See all rule blocks and validation methods
• Understand exactly what is being validated
• Identify potential policy issues affecting compliance results

Cannot edit from this view: To modify policy definition, navigate to Policy Definitions section and edit directly. Changes apply to all assignments using that definition.

Viewing Compliance Results

From expanded assignment view, click View Compliance to see results for this assignment.

Results navigation: Directly jumps to compliance report filtered for this specific assignment, showing:

• Per-device compliance status (PASS/FAIL)
• Individual rule results
• Last evaluation timestamp
• Detailed failure information for remediation

See Policy Compliance Results for complete guide to interpreting and acting on compliance results.

Deleting Assignments

Delete assignments that are no longer needed or were created for testing.

Before deleting:

• Verify assignment is not needed for compliance tracking
• Consider disabling instead of deleting if might be needed later
• Export compliance history if needed for audit purposes
• Document reason for deletion

Deletion impact:

• Assignment configuration is permanently removed
• Historical compliance results remain accessible in database (subject to retention policies)
• Scheduled tasks referencing this assignment will fail—remove or update scheduled tasks first

Tip

If uncertain whether an assignment will be needed in the future, disable it instead of deleting. Disabled assignments preserve configuration and history while preventing execution.

Assignment Strategies

Device-Level Assignments

When to use:

• Testing new policies before broad deployment
• Special compliance requirements for specific devices
• Troubleshooting policy issues on individual devices
• One-off validation scenarios

Example scenarios:

• Test new security baseline on single router before applying to all routers
• Critical device has unique compliance requirements not shared by others
• Validate policy works correctly before scaling to category or tag

Advantages:

• Granular control and minimal impact
• Easy troubleshooting with single device
• Low risk for testing

Disadvantages:

• Doesn’t scale—manual assignment per device
• Difficult to maintain as network grows
• Devices don’t automatically inherit policies

Category-Based Assignments

When to use:

• Device type-specific compliance (all routers, all switches, all firewalls)
• Vendor-specific policies (Cisco IOS requirements, Juniper JUNOS standards)
• Role-based compliance (core layer, distribution layer, access layer)

Example scenarios:

• All Cisco routers must meet IOS security baseline
• All HP switches require specific SNMP configuration
• All firewalls must comply with security policy framework

Advantages:

• Automatic inheritance—devices in category automatically inherit policies
• Scales well with network growth
• Logical organization by device type or role
• Easy to understand and maintain

Disadvantages:

• Requires well-maintained device categories
• Less flexible than tags for cross-cutting concerns
• Device can only be in one category

Tag-Based Assignments

When to use:

• Cross-cutting compliance requirements (production vs. lab, PCI scope, geographic location)
• Flexible grouping beyond device type (critical infrastructure, internet-facing, management network)
• Temporary or project-based compliance tracking

Example scenarios:

• All production devices require standard NTP/DNS regardless of type
• Devices in PCI scope require specific security configurations
• Devices in DataCenter-A have different DNS servers than DataCenter-B

Advantages:

• Maximum flexibility—devices can have multiple tags
• Cross-cutting policies span device types
• Easy to add/remove devices from compliance scope
• Support temporary groupings for projects

Disadvantages:

• Requires disciplined tag management
• Can become complex with many overlapping tags
• Less intuitive than category-based organization

Smart Group Assignments (V8.2.1+)

Best for: Dynamic device populations whose membership changes as devices are imported, retired, or relabelled.

Common patterns:

• Vendor + version: “Cisco IOS routers running 15.x” (Smart Group rules: vendor = Cisco AND model contains IOS AND version starts with 15)
• Status + tag: “Active devices tagged Production” (Smart Group rules: status = active AND tag includes Production)
• Imported set: “Devices originating from Netbox in the DMZ site” (Smart Group rules: origin_system = netbox AND custom property site = DMZ)

Why use them over Tags: Tags are static labels you set per device; Smart Groups are saved filters that re-evaluate at compliance time. New devices that match the rules join automatically and old ones drop out, no per-assignment edits required.

Caveat: Keep the Smart Group homogeneous so its devices share a Command Group. The first matching device’s Command Group sets the available command list, so heterogeneous Smart Groups either need to be split or use a command name that exists across all members’ Command Groups. See the Smart Groups page for the underlying primitive.

Multi-Assignment Strategies

Layered compliance: Use multiple assignments to validate different aspects of device configuration.

Example layered approach:

Device: Core-Router-01
├── Assignment 1: Security-Baseline (Category: Routers)
│   └── Validates: Enable secret, SSH, AAA, no Telnet
├── Assignment 2: Standard-Services (Tag: Production)
│   └── Validates: NTP, DNS, SNMP, Logging
├── Assignment 3: Interface-Standards (Category: Routers)
│   └── Validates: Interface descriptions, no shutdown
└── Assignment 4: PCI-DSS-Requirements (Tag: PCI-Scope)
    └── Validates: Encryption, access controls, logging

Benefits of layered approach:

• Modular policies easier to maintain
• Clearer reporting—failures isolated to specific compliance area
• Flexible policy application—apply some policies broadly, others selectively
• Testing simplified—disable specific layer without affecting others

Assignment Best Practices

Naming Conventions

Use consistent, descriptive names: Establish and follow naming conventions across all assignments.

Recommended format: [Scope]-[PolicyArea]-[Purpose]

Examples:

• Routers-Security-Baseline
• Production-Devices-Standard-Services
• PCI-Scope-Security-Requirements
• Core-Switches-Interface-Standards

Include:

• Scope type/name for context
• Policy focus for quick identification
• Purpose or compliance area

Avoid:

• Generic names: Policy1, Assignment-Test
• Unclear abbreviations: Prod-SW-Cfg-1
• Inconsistent formats across assignments

Documentation

Use description field: Always provide detailed descriptions explaining:

• Why assignment exists
• What compliance it enforces
• Any exceptions or special considerations
• Related tickets, change requests, or audit requirements

Example description:

Enforces PCI-DSS security baseline requirements for all devices
in cardholder data environment. Validates encryption, access
controls, and logging as required by PCI-DSS v3.2.1 sections
2.2, 2.3, and 8.1. Created per ticket SEC-2024-156.

Testing Before Production

Always test new assignments:

1. Create assignment with status Disabled
2. Test manually on single device or small group
3. Review results and adjust policy or assignment if needed
4. Enable assignment for production enforcement
5. Monitor initial results for unexpected failures

Incremental rollout:

1. Start with device-level assignment for testing
2. Expand to small category or tag
3. Validate results across broader scope
4. Finally apply to full production population

Scope Management

Keep scopes organized:

• Maintain clean category structure
• Use tags consistently across devices
• Document tag purposes and usage
• Regularly audit device categorization and tagging

Avoid scope overlap confusion:

• If device is in multiple scopes with same policy, it will be evaluated multiple times (not harmful but inefficient)
• Use layered approach with different policies for each scope rather than duplicating policies

Command Selection

Verify command availability:

• Ensure command exists in device command groups
• Confirm command executes successfully during backups
• Check command output contains configurations policy evaluates

Use appropriate command granularity:

• Prefer specific commands over large dumps
• show running-config for most configuration validations
• show version for version/hardware validation
• Targeted commands for specific feature validation

Maintenance and Review

Regular review cycle:

• Monthly: Review assignment enabled/disabled status
• Quarterly: Validate assignments still align with compliance requirements
• After major changes: Review affected assignments for continued relevance
• Audit period: Verify assignments meet current regulatory requirements

Clean up obsolete assignments:

• Delete or disable assignments no longer needed
• Archive historical compliance data if required
• Document reasons for assignment removal

Troubleshooting Assignments

Assignment Not Executing

Symptoms: Compliance results don’t appear for assignment despite enabled status.

Possible causes:

1. Assignment disabled: Verify enabled status in assignment configuration
2. No devices in scope: Category or tag has no assigned devices
3. Scheduled task not configured: Manual execution required if no scheduled task
4. Horizon queue issues: Compliance jobs not processing

Resolution:

1. Check assignment enabled status
2. Verify devices exist in selected scope (category/tag membership)
3. Run manual compliance check to validate assignment
4. Review Horizon queue for failed compliance jobs
5. Check application logs for assignment-related errors

All Devices Failing Compliance

Symptoms: Every device in assignment scope fails compliance, even known-good devices.

Possible causes:

1. Policy definition error: Rules don’t match actual device configuration format
2. Wrong command selected: Command output doesn’t contain configurations policy validates
3. Case sensitivity issues: Policy strings don’t match device output case
4. Configuration not downloaded: Devices missing recent configuration files

Resolution:

1. Review policy definition against actual device configuration
2. Verify command output contains configurations being validated
3. Test policy against known-good device manually
4. Check case sensitivity in policy strings
5. Ensure devices have recent backup files for selected command

Some Devices Show “NOT EVALUATED - CONFIG NOT FOUND”

Symptoms: Some devices in scope show “NOT EVALUATED” instead of PASS/FAIL.

Cause: Configuration file for selected command doesn’t exist for those devices.

Resolution:

1. Verify affected devices are backing up successfully
2. Confirm selected command exists in device command groups
3. Check backup logs for command execution failures
4. Run manual device backup to generate missing configuration files
5. Re-run compliance check after successful backups

Assignment Results Inconsistent

Symptoms: Same device shows different results between compliance runs without configuration changes.

Possible causes:

1. Policy definition modified: Rules changed between compliance runs
2. Configuration actually changed: Device configuration modified between evaluations
3. Command output varies: Dynamic content in command output affects evaluation
4. Timing issues: Compliance check ran before backup completed

Resolution:

1. Review policy definition change history
2. Check device configuration history for changes
3. Verify policy rules don’t evaluate dynamic content (timestamps, uptime)
4. Ensure compliance checks run after backups complete
5. Schedule compliance tasks with appropriate delays after backup tasks

Smart Group Assignment Shows Fewer Commands than Expected (V8.2.1+)

Symptoms: When the scope type is Smart Groups, the Command dropdown lists commands from one Command Group only, even though the Smart Group resolves to devices across several Command Groups.

Cause: By design. Available commands are derived from the first matching device’s Command Group. Heterogeneous Smart Groups silently exclude devices outside that group from compliance for the chosen command.

Resolution:

1. Tighten the Smart Group rules so it resolves to a single Command Group, or
2. Split into multiple assignments, one per Command Group your policy needs to cover.

The amber heads-up note in the assignment dialog flags this when Smart Groups is selected.

Auto Compliance Run Not Producing a Report (V8.2.1+)

Symptoms: A device finished a successful backup but no Auto - post-backup report appeared in the Compliance Reports list for the expected assignment.

Possible causes:

1. Assignment is disabled.
2. Run on backup is off on the assignment.
3. The device is no longer in scope of the assignment (Smart Group / Tag / Category membership changed).
4. The compliance worker on the PolicyCompliance queue is not running or is backlogged.

Resolution:

1. Re-open the assignment and confirm both Enabled and Run on backup are on.
2. Confirm the device still resolves into the assignment’s scope (run the assignment manually and check device coverage).
3. Check Horizon for the PolicyCompliance queue depth and any failed jobs.
4. If queues look healthy, click Re-run compliance on the device’s Compliance tab to force a per-device evaluation immediately.

Cannot Delete Assignment

Symptoms: Delete operation fails or is blocked.

Cause: Scheduled tasks may reference the assignment.

Resolution:

1. Identify scheduled tasks using this assignment
2. Delete or update scheduled tasks to remove assignment reference
3. Retry assignment deletion
4. Alternatively, disable assignment instead of deleting if scheduled tasks need preservation

Related Documentation

• Compliance Overview - Understanding the compliance system architecture
• Policy Definitions - Creating compliance rules
• Policy Compliance Results - Reviewing and acting on compliance reports
• Scheduled Tasks - Automating compliance checks
• Horizon Queue Manager - Monitoring compliance job execution

Quick Reference

Assignment Configuration Rules

1. One scope per assignment (device, category, OR tag)
2. One command per assignment
3. One policy definition per assignment
4. Multiple assignments can use same policy definition
5. Assignments can be disabled for testing

Scope Selection Guide

Scope Type	Use When	Example
Device	Single device, testing, unique requirements	Critical core router
Category	Device type, vendor, or role-based policies	All Cisco routers
Tag	Cross-cutting concerns, flexible grouping	All production devices

Assignment Creation Checklist

• Descriptive name following conventions
• Detailed description with purpose
• Appropriate scope selected (device/category/tag)
• Command contains configurations policy validates
• Policy definition tested and validated
• Enabled status set correctly
• Tested with manual compliance check
• Results reviewed and confirmed
• Scheduled task created (if needed)
• Documentation updated

Troubleshooting Quick Checks

• Assignment enabled
• Devices exist in scope
• Command exists in device command groups
• Policy definition syntax valid
• Recent backups exist for devices
• Horizon processing compliance jobs
• Application logs reviewed for errors

Summary

Policy Assignments are the operational bridge between policy definitions and device populations, enabling flexible, scalable compliance enforcement across network infrastructure. Proper assignment configuration—selecting appropriate scope, matching commands to policy content, and following best practices—ensures compliance validation produces meaningful, actionable results.

Key Takeaways

Flexible scoping: Device, category, and tag-based assignments provide granular to broad compliance enforcement, adapting to any organizational structure or compliance requirement.

Command-policy alignment: Selecting command output that contains configurations policy validates is critical to assignment success. Misaligned selections cause false failures or missed validations.

Testing and validation: Always test new assignments on small scopes before production deployment, using disabled status during testing to prevent false compliance reports.

Layered approach: Multiple assignments on same devices validate different compliance aspects, providing comprehensive yet organized compliance coverage without policy definition complexity.

Regular maintenance: Review assignments periodically to ensure continued alignment with compliance requirements, removing obsolete assignments and updating as network evolves.

With properly configured policy assignments linking tested policy definitions to appropriate device scopes and commands, rConfig provides reliable, automated compliance validation that scales from single devices to enterprise networks with thousands of devices.