# Investigating Security Events AccessIQ maintains a HIPAA-compliant audit trail with 7-year retention. This guide shows you how to use audit logs to investigate failed logins, unauthorized access, role changes, and impersonation sessions. *** ## Before You Begin * You need the **Owner** or **Admin** role to access audit logs. * Audit logs are read-only. You cannot modify or delete log entries. *** ## Accessing Audit Logs 1. Go to **Audit & Monitoring > Audit Logs** in the sidebar. 2. The page displays a table of recent events, sorted by most recent first. 3. Each row shows: | Column | Description | | ---------- | ----------------------------------------------------------------------------- | | Timestamp | When the event occurred | | User | The name and email of the user who performed the action | | Action | The event type code (e.g., `LOGIN_SUCCESS`, `CREATE_USER`, `ROLE_CHANGE`) | | Resource | The type and name of the affected resource (User, Organization, Role, Tenant) | | Status | Success, Failure, or Warning | | Risk | Risk score badge -- Low, Medium, or High | | IP Address | The IP address the request originated from | *** ## Filtering Audit Logs Click the **Filters** button in the top-right corner to open the filter panel. Available filters: | Filter | What It Does | | -------------------- | ------------------------------------------------------------------------------------------------- | | User ID | Show events for a specific user (enter their UUID) | | Action | Filter by action type (e.g., `CREATE_USER`, `LOGIN_FAILURE`, `ROLE_CHANGE`) | | Resource Type | Narrow to a resource category: User, Organization, Role, Tenant, or Patient | | Status | Show only Success, Failure, or Warning events | | Start Date | Events on or after this date and time | | End Date | Events on or before this date and time | | Show only PHI access | When checked, shows only events that involved Protected Health Information (for HIPAA compliance) | After setting your filters, click **Apply Filters**. To reset, click **Clear Filters**. > **Tip:** The active filter count appears as a badge on the Filters button so you can see at a glance whether filters are applied. *** ## Investigation Scenarios ### Scenario 1: Failed Login Attempts A user reports they cannot sign in, or you want to check for brute-force attempts. 1. Open the filter panel. 2. Set **Action** to `LOGIN_FAILURE`. 3. If investigating a specific user, enter their **User ID**. 4. Set the **Start Date** and **End Date** to the relevant time window. 5. Click **Apply Filters**. 6. Review the results: * Look at the **IP Address** column. Multiple failures from the same IP may indicate a brute-force attack. * Look at the **Risk** column. High-risk events (score 80+) are highlighted with a red background. * Check whether the failures are for a single user (credential issue) or many users (possible system issue). **When to escalate:** If you see more than 10 failed login attempts from the same IP within a short window, or if failures span multiple user accounts, consider blocking the IP or enabling additional security measures under **Security > Security Settings**. *** ### Scenario 2: Unauthorized Access Attempts You want to check if users are trying to access resources they should not have. 1. Open the filter panel. 2. Set **Status** to `FAILURE`. 3. Set **Resource Type** to the resource category of interest (e.g., Organization, Role). 4. Click **Apply Filters**. 5. Review the results: * The **Action** column shows what was attempted (e.g., `UPDATE_ORGANIZATION`, `ASSIGN_ROLE`). * The **User** column shows who attempted the action. * The **Resource** column shows the target of the attempt. **When to escalate:** If a user is repeatedly attempting actions outside their authorized scope, review their role assignments under **Access Control > Roles & Permissions** and consider whether their access needs to be adjusted or revoked. *** ### Scenario 3: Role and Permission Changes You need to audit who changed user roles or permissions, and when. 1. Open the filter panel. 2. Set **Action** to `ROLE_CHANGE` (or search for related actions like `ASSIGN_ROLE`, `REMOVE_ROLE`). 3. Set **Resource Type** to `Role`. 4. Set the date range to the period you want to audit. 5. Click **Apply Filters**. 6. For each event, note: * **Who** made the change (the User column). * **What** was changed (the Resource column shows the affected role or user). * **When** the change happened (the Timestamp column). > **Tip:** Cross-reference role change events with the user's current permissions on the **Access Control > Permission Matrix** page to see the current state. **When to escalate:** Unexpected role elevations (e.g., a Member being promoted to Owner) or bulk role changes outside of a planned maintenance window should be investigated immediately. Check if the admin who made the change was authorized to do so. *** ### Scenario 4: Impersonation Sessions Admins can impersonate users to troubleshoot issues. All impersonation sessions are logged. 1. Open the filter panel. 2. Set **Action** to `IMPERSONATE` (or search for impersonation-related actions). 3. Click **Apply Filters**. 4. For each event, review: * **Who** initiated the impersonation (the User column shows the admin). * **What** user was impersonated (shown in the Resource column). * **When** and for how long the session lasted. Impersonation is also visible on the **User Management > Users** page. When an admin clicks the impersonate button on a user row, they must provide a reason, which is recorded in the audit log. **When to escalate:** Impersonation without a documented business reason, or impersonation of high-privilege accounts, should be flagged for review with your security team. *** ## Exporting Audit Logs You can export filtered or unfiltered audit logs for offline analysis or compliance reporting. 1. Apply any filters you want to scope the export. 2. Click **Export CSV** to download a comma-separated file, or **Export JSON** for a structured data file. 3. The export includes up to 1,000 events matching your current filters. 4. The file downloads automatically with a timestamped filename (e.g., `audit-logs-2026-03-31T10:00:00.csv`). > **Tip:** For compliance audits, export the full event set as JSON, which preserves all metadata fields. CSV is better for quick review in a spreadsheet. *** ## Monitoring Login History For a focused view of authentication events, use the dedicated login history page: 1. Go to **Security > Login History** in the sidebar. 2. This page shows login attempts with additional detail like browser, device, and location. 3. Use this alongside audit logs to get a complete picture of authentication activity. *** ## Risk Score Reference Audit events include a computed risk score. The score determines the badge displayed in the Risk column: | Score Range | Badge | Meaning | | ----------- | ----------- | ------------------------------------------------------- | | 0--49 | Low Risk | Routine activity, no concern | | 50--79 | Medium Risk | Unusual but not necessarily malicious; worth monitoring | | 80--100 | High Risk | Potentially malicious activity; investigate promptly | Events with a risk score of 70 or higher are highlighted with a red background in the audit log table. *** ## When to Escalate Escalate to your security team or AccessIQ support when you see: * **Sustained brute-force patterns** -- More than 10 failed logins from a single IP in under 5 minutes. * **Credential stuffing indicators** -- Failed logins across many different user accounts from similar IPs. * **Unauthorized privilege escalation** -- Role changes that were not approved through your change management process. * **Unexplained impersonation sessions** -- Impersonation of users without a support ticket or documented reason. * **High-risk events from unfamiliar IPs** -- Events with risk scores above 80 from IP addresses not in your trusted network ranges. * **PHI access anomalies** -- Unexpected access to Protected Health Information outside of normal workflows. For trusted network configuration, go to **Security > Trusted Networks** to define IP ranges that are considered safe. *** ## What's Next * [Set up SSO](/accessiq-docs/getting-started/setting-up-sso.md) to centralize authentication and reduce password-related security events. * [Onboard a customer](/accessiq-docs/getting-started/onboarding-a-customer.md) with proper role assignments to minimize unauthorized access attempts. * Configure **Audit Streaming** (under Audit & Monitoring) to send events to your SIEM or log aggregation system in real time. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://accessiq.gitbook.io/accessiq-docs/getting-started/investigating-security-events.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.