| Time | Severity | Category | Event Type | Actor | Description | IP Address |
|---|
✓ MFA is Active
Two-factor authentication is enabled on your account using an authenticator app.
Disable MFA
Enter your current TOTP code to confirm. This removes two-factor protection from your account.
Set Up Two-Factor Authentication
Protect your account with an authenticator app. Works with Google Authenticator, Authy, 1Password, and any TOTP app.
Scan QR Code
Open your authenticator app and scan this QR code. Or manually enter the secret key.
✓ MFA Enabled!
⚠ Save these backup codes now. Each can only be used once. Store them securely — this is the only time they'll be shown.
Platform defaults shown. These comply with GLBA financial record requirements (7 years).
| Time | User | Role | Action | Entity Type | Entity | IP |
|---|---|---|---|---|---|---|
| No events | ||||||
| Time | Actor | Role | Action Type | Entity | Summary |
|---|---|---|---|---|---|
| No actions | |||||
Data Processing Agreement (DPA) Template
DATA PROCESSING AGREEMENT
This Data Processing Agreement ("DPA") is entered into between [FIRM NAME] ("Controller") and Ledgr ("Processor"), and is incorporated into and forms part of the Ledgr Terms of Service.
1. Definitions
"Personal Data," "Processing," "Controller," and "Processor" have the meanings given in applicable data protection laws including GLBA and applicable state privacy statutes.
2. Processing Instructions
Processor shall process Personal Data only on documented instructions from Controller, including for the purposes of providing the Ledgr platform as described in the Terms of Service and Privacy Policy.
3. Security Measures
Processor shall implement appropriate technical and organizational security measures as described in the Ledgr Security Center, including encryption at rest (AES-256) and in transit (TLS 1.2+), access controls, audit logging, and incident response procedures.
4. Subprocessors
Processor may engage the subprocessors listed in the Ledgr Security Center (Subprocessor Registry). Processor shall notify Controller of any changes to subprocessors with at least 30 days' advance notice where practicable.
5. Data Subject Rights
Processor shall assist Controller in fulfilling data subject rights requests (access, deletion, correction) within 30 days of instruction from Controller.
6. Breach Notification
Processor shall notify Controller without undue delay (and within 72 hours where feasible) upon becoming aware of a Personal Data breach affecting Controller's data.
7. Deletion and Return
Upon termination, Processor shall provide Controller a data export and delete all Personal Data within 90 days, except where retention is required by law.
8. Audit Rights
Controller may audit Processor's compliance with this DPA upon 30 days' written notice, no more than once per year, at Controller's expense.
9. GLBA Service Provider Requirements
Processor acknowledges its obligations as a service provider under the GLBA Safeguards Rule (16 C.F.R. Part 314) and shall maintain safeguards consistent with § 314.4 requirements.
To execute this DPA: email legal@ledgr.com with subject "DPA Execution Request — [Firm Name]". Executed DPAs are stored in your organization's compliance file.
Subprocessor Registry
| Name | Purpose | Data Processed | Location | Compliance | DPA Status |
|---|---|---|---|---|---|
| Loading… | |||||
Severity Classification
- Confirmed unauthorized access to client PII or financial data
- Loss or theft of unencrypted sensitive data
- Multi-org data exposure or cross-tenant breach
- Ransomware or active system compromise
- Platform unavailability affecting multiple orgs (>30 min)
- Suspected but unconfirmed data access
- Auth system failure or mass lockout
- Critical third-party integration failure (database, storage)
- Detected intrusion attempt (unsuccessful)
- Anomalous access patterns requiring investigation
- Single-org partial service degradation
- Credential compromise of a single user account
- Failed attack or vulnerability discovered proactively
- Minor policy violation (no data exposure)
- Isolated user access error, self-corrected
- System anomaly that resolved without impact
Response Phases
- Detect the incident via alerts, user reports, or automated monitoring
- Determine whether the event constitutes an incident (vs. false positive)
- Assign a severity level (P1–P4)
- Document: when discovered, how discovered, what systems/data involved
- Create incident record in Security Center → Incidents tab
- Notify Super Admin team and begin incident log
- Isolate affected systems or accounts (revoke sessions, rotate credentials)
- Prevent further unauthorized access or data exfiltration
- Preserve evidence (audit logs, access records, timeline)
- For P1: consider emergency shutdown of affected services if necessary
- For P1/P2: notify affected org admins via Security Center notification
- Engage legal counsel if PII breach is confirmed or suspected
- Update incident record: status → investigating → contained
- Identify and eliminate the root cause (patch vulnerability, revoke access, etc.)
- Confirm all attack vectors are closed
- Scan for any secondary compromise or persistence mechanisms
- Rotate all potentially compromised credentials and tokens
- Document all actions taken
- Restore normal operations, verify system integrity
- Monitor closely for 48–72 hours post-recovery
- Confirm no residual unauthorized access exists
- For P1: coordinate affected-individual notification per legal guidance
- Update incident record: status → resolved
- Communicate resolution status to affected org admins
- Complete post-mortem within 2 weeks of incident resolution
- Document: what happened, root cause, impact, timeline, what was done
- Identify control gaps and remediation actions
- Assign owners and deadlines for remediation items
- Update WISP and risk register if controls need adjustment
- Complete in incident record: use Post-Mortem template in Incidents tab
Role Assignments During Incident
| Role | Responsibilities During Incident | Who |
|---|---|---|
| Incident Commander | Overall coordination; severity/scope decisions; external communications authorization; legal/regulatory escalation decision | Platform Super Admin (lead) |
| Technical Lead | Root cause investigation; system isolation; evidence preservation; remediation execution; infrastructure recovery | Engineering lead |
| Org Admin Liaison | Notification of affected org admins; answering firm-specific questions; coordinating per-org impact assessment | Account/success team or Super Admin |
| Legal Counsel | Regulatory notification timing decisions; affected-individual notification review; insurance engagement; privilege protection | 📋 External — requires engagement |
| Affected Org Admins | Notification of their firm; assessment of impact to their clients; GLBA notification decisions for their clients | Org-level (notified via Security Center) |
Contact List Template
Legal Requirements & Notification Timelines
| Framework | Trigger | Who Notifies | Timeline | Status |
|---|---|---|---|---|
| GLBA Safeguards Rule (FTC) | Unauthorized access to unencrypted customer financial information | Financial institution (your firm) notifies FTC & affected customers | 30 days (FTC notification as soon as reasonably possible) | 📋 Legal Required |
| CCPA (California) | Unauthorized access to CA resident nonencrypted personal information | Business notifies affected CA residents | In "expedient time" (no specific deadline) | 📋 Legal Required |
| State Breach Notification Laws | Unauthorized access to personal information as defined per state | Business notifies affected residents and/or state AG | Varies: 30–72 hours (confirm with counsel per state) | 📋 Legal Required |
| SEC Cybersecurity Rules (RIAs) | Material cybersecurity incident affecting RIA | RIA notifies SEC on Form ADV-C | Within 48 hours of materiality determination | 📋 Legal Required |
| ID | Severity | Title | Status | Discovered | Affected Orgs | Actions |
|---|---|---|---|---|---|---|
| No incidents — good! | ||||||
| Time | User | Role | Action | Record Type | Record | IP |
|---|---|---|---|---|---|---|
| No access events found | ||||||