Compliance & audit

Compliance and audit in Elliptic

Elliptic gives an organization four tools for governance and recordkeeping, all gathered under the Compliance & Audit group in Settings. You declare your compliance posture, handle GDPR data-subject and right-to-erasure requests, read a filterable audit log of every recorded change, and read a dedicated trail of every membership and role change. These live on the Compliance, Audit log, and Role audit tabs, and they are admin work.

Because agents are first-class members in Elliptic, the same recordkeeping covers them. When an agent moves a task, files a note, or is added to a project, that lands in the same audit log and, where access changes, the same role audit. Each audit-log entry carries an actor type, so you can see at a glance whether an action came from a person or the system.

Compliance posture

Your compliance posture is a declared, recorded statement of how your organization handles data. It is stored as four fields on the organization itself, set on Settings → Compliance, and any member can read it through the compliance endpoint while only admins can change it. It is a declaration for your records and your auditors, not an enforcement switch. In the words of the settings screen itself, the residency region is "a recorded, audited declaration (not enforced storage sharding)."

The posture has four parts:

1. 1
   Open the Compliance tab

   Go to Settings and open the Compliance tab under Compliance & Audit. You land on the Compliance & data residency section.
2. 2
   Set the residency region

   Pick a region from the Data residency region dropdown. Choosing Not declared clears it. The change saves as soon as you select it.
3. 3
   Toggle your frameworks

   Check the boxes for the frameworks you assert against. Each one toggles on its own and saves immediately, so you can claim, for example, soc2 and gdpr together.
4. 4
   Record the controller and DPO

   Fill in Data controller with your legal entity and DPO contact with your data protection officer's contact. Each field saves when you click away from it. Clearing a field and clicking away removes the value.

GDPR data-subject requests

When a member exercises a data-subject access request under GDPR, you assemble a data-subject export bundle for them, a single document that gathers what Elliptic holds about that person inside your organization. You file it from the Data-subject requests (GDPR) section on the same Compliance tab, and the same section is where you file a right-to-erasure request.

Assembling a data-subject export bundle

The bundle has two parts. The subject part is the member's personal data Elliptic stores: their user id, email, full name, and their role in your organization. The content part is a privacy-respecting count of what they have authored, the number of authored tasks, authored notes, and authored comments, rather than the content itself. The bundle is built only for someone who is actually a member of your organization. Asking for a non-member returns a not-found error.

1. 1
   Pick the member

   In Data-subject requests (GDPR), choose the person from the Select a member dropdown. It lists everyone in your organization by name, or by email when they have no name set.
2. 2
   Export the data

   Click Export data. Elliptic assembles the bundle and downloads it to your machine as a JSON file named data-subject-<user-id>.json.
3. 3
   Hand it over

   Deliver the JSON file to the data subject, or retain it as the record of what you fulfilled. The file is the full bundle, ready to attach to your response.

The downloaded JSON looks like this:

{
  "subject": {
    "id": "<user-id>",
    "email": "jordan@example.com",
    "full_name": "Jordan Lee",
    "role": "member"
  },
  "content": {
    "authored_tasks": 42,
    "authored_notes": 7,
    "authored_comments": 118
  }
}

Filing a right-to-erasure request

When a member asks to be erased, you file a right-to-erasure request. From the same section, with the member selected, click Request erasure. Elliptic records the request against your organization and returns a status of pending_review. The request is logged for review, it does not delete the member or their content on the spot, so an admin makes the deletion decision deliberately rather than as a side effect of a button press.

The audit log

The audit log is the org-wide compliance view over everything Elliptic records: every meaningful change to a task, project, note, comment, or the organization, with the actor who made it, when it happened, and the before/after values. It is the activity history read through a governance lens, on Settings → Audit log, and it is admin-only. Each entry tells you who did it, what they touched, what event it was, and what changed.

Filtering

The log is paginated, newest first. You narrow it with these filters:

• Entity type — the kind of thing that changed: task, project, organization, note, comment, cycle, milestone, or release. The default is All entities.
• Date range — a From and To date that bound the window. Each bound is inclusive of its whole day.

In the table, each row shows when it happened, the actor (with a system badge for automated actions whose actor resolves to System), the humanized event, the entity type, and the changed fields rendered as a compact key: value list. Rows with no recorded field changes show a dash.

CSV export

Click Export CSV to download the log as a spreadsheet-ready file named audit-log.csv. The export honors whatever filters you currently have applied, so you can scope it to a single entity type or a date range before downloading. The export returns up to 5000 rows in one file.

The CSV carries these columns:

timestamp, actor, actor_type, entity_type, entity_id, event, changes

The role and permission audit

The role and permission audit is a dedicated trail for one question: who changed whose access, from what to what, and when. It is separate from the general audit log because every row carries the role before and the role after of the change, so access decisions are legible on their own without digging through the wider activity stream. You read it on Settings → Role audit, and it is admin-only.

The trail is written automatically whenever access changes in the organization. Inviting a member, a member being added when they accept an invite, removing a member, and changing a member's org role each append one immutable record. The same machinery covers project and team membership changes as well, so the scope of a row tells you which surface the change touched.

Filtering

Like the audit log, this trail is paginated, newest first, and filterable. You narrow it by:

• Action — the kind of change, such as Member invited or Org role changed. The default is All actions.
• Scope — org, project, or team, the surface the grant belongs to. The default is All scopes.
• Date range — a From and To bound, each inclusive of its full day.

Each row shows when it happened, the actor, the humanized action, the subject (falling back to the invited email for an invite that has no resolved member yet), a scope badge, and the change rendered as role_before → role_after. A row with no role transition, such as a plain removal, shows a dash.

CSV export

Click Export CSV to download the trail as rbac-audit.csv. As with the audit log, the export respects your current filters and returns up to 5000 rows. It is the richer of the two exports, carrying the subject, the scope, and both role values on every row:

timestamp, actor, actor_type, subject, scope, resource_id, action, role_before, role_after, detail