User Policies
Defining User Policies
User Policies within the LightBeam Governance module define the rules that control how users access sensitive data across the organization. These policies help ensure that data access aligns with security requirements and regulatory standards by allowing organizations to clearly specify who can access what information and under which conditions. Through User Policies, organizations can consistently enforce governance expectations and reduce the risk of unauthorized access.
Navigating to the Policies Section

To access the configuration and monitoring tools within the Governance module:
Navigate to the top navigation bar on the home screen.
Click on the Playbooks tab.
From the dropdown menu, select Policies.
Then scroll to the middle of the screen to view the Users widget within the Governance section.
Rule Set Creation and Variations

To manage your environment effectively, you can configure rule sets in the Users widget within the Governance section. These rules allow the system to monitor specific user behaviors and raise alerts when criteria are met. The system allows for several variations of user policies to be created:


Inactive Users: This policy identifies users who have not logged into the system within a defined period. While the default is typically six months, this timeframe is fully configurable. For inactive users, the alert is based on a configurable timeframe of inactivity, with optional criteria based on access to high-sensitivity data or the number of objects they have access to.
Deactivated Users: These are users who are either disabled or deleted within the Active Directory (AD). You can specify alerts for both or choose only one of these statuses.
Guest or External Users: This policy distinguishes between Guest Accounts (which are AD accounts designated as guests) and External Users (those not in the AD but who have had files shared with them, detected during system scans).
Creating New Rule Set
Rule Set Criteria: Specify the conditions that constitute a violation. For each policy, you can refine the criteria to focus on high-risk scenarios. You have the flexibility to set the sensitivity (e.g., only alerting if the user has access to "High" or "Medium" sensitive data), specific attributes, and the entity or data source involved. You can combine these filters—for example, alerting only if a user has been inactive for three months and has access to more than ten high-sensitivity objects.



Active Directories: Once the logic is defined, you must select the scope of the policy. You can choose to evaluate one or multiple Active Directories (AD) or Identity Providers (IDP). This includes selecting the specific data sources (SharePoint, Google Drive, SMB) or organizational units the policy should govern.

Alerts & Notifications: Configure the triggers and delivery methods for your notifications, and designate the specific security teams or individuals responsible for responding.


Automation: You can choose to automate responses to these alerts to save time and improve security:
Account Actions: Automatically disable an account either immediately or after a specific delay once a user matches the policy criteria.
Object Reassignment: Automatically transfer ownership of files owned by the inactive or disabled user. You can designate the Data Source Owner, the user’s Manager (pulled from the AD), or a Custom User as the recipient. A delay can also be configured to ensure the transition is managed correctly.


Alert Management

The alert interface is standardized across all user policy types, providing a consistent experience regardless of whether you are reviewing an inactive user or an external guest. Alerts ensure that administrators are notified the moment a policy is breached.
The Alert Overview


When an alert is raised, the dashboard provides a comprehensive overview of the risk, showing exactly what the alert looks like and who is involved:
Impacted Users: A clear count and list of how many users have triggered the policy.
Owned Objects: Detailed data showing exactly how many objects each user owns, which specific objects they are, and how many different sources they originate from.
User Context: Metadata such as the user’s Department, Employment Type, and current Account Status (e.g., Active or Disabled).
Time Stamp and State: Every alert includes a precise time stamp of the occurrence and the current State of the alert (e.g., Open or Resolved).
Manual Actions and History

If you prefer not to use automation, you can take manual actions directly from the alert screen. You have the option to Suspend User (which revokes access and marks them as suspended in the AD) or manually trigger the Reassign Files process to a fallback owner.
To ensure accountability, you can check the History Log at any time. This provides a full audit trail of all transactions and actions taken against a specific alert, ensuring you have a complete record of governance activities for auditing and compliance purposes.
Purpose and Utility
Unified Risk Oversight: Consolidates diverse user risks—including inactive, guest, and deactivated accounts—into a single governance framework to eliminate security blind spots.
Operational Efficiency through Automation: Reduces the manual burden on IT teams by automatically reassigning data ownership and disabling high-risk accounts based on customized triggers.
Regulatory Alignment: Simplifies the process of meeting stringent data protection standards by maintaining a permanent, searchable history log of all access changes and policy remediations.
Contextualized Decision Making: Empowers administrators to make informed security choices by providing deep user context, such as department, employment status, and specific object ownership, within every alert.
Proactive Lifecycle Management: Facilitates the continuous cleanup of digital footprints by identifying and managing the data legacy of external users and former employees.
Last updated