Figma logging & audit security checks
Audit logs, event retention and incident-response hooks — the evidence you need when something goes wrong, and the controls auditors ask for first.
On Figma, Black Cat runs 3 checks in this area on every scan. Each one below lists its severity, how to fix it, and the compliance controls it satisfies where a control applies. See what access the Figma connector needs.
Checks (3)
severity: low Account Not Org-Scoped (No Audit Visibility) fix difficulty: easy #
Configure an org-scoped Enterprise token so Figma activity/audit logs are collected
- Confirm the connector is configured with an org_id and an Enterprise token
- Verify the token has the org:activity_log_read scope
- Re-run the scan and confirm activity events are returned
Satisfies: NIS2 Directive NIS2-21.b.2 DORA (SaaS Security) DORA-10.1
severity: info Activity Permission Change Event fix difficulty: easy #
Review file sharing/permission-change events captured in the activity log
- Open Figma Admin > Activity logs and review the permission-change event
- Confirm the change was authorized and the new access is least-privilege
- Revert any unintended sharing change
Satisfies: NIS2 Directive NIS2-21.b.2 DORA (SaaS Security) DORA-10.1
severity: info Activity Member Role Change Event fix difficulty: easy #
Review member/role-grant events captured in the activity log
- Open Figma Admin > Activity logs and review the membership/role-change event
- Confirm the role grant or admin promotion was authorized
- Downgrade or revoke any unintended privilege
Satisfies: NIS2 Directive NIS2-21.b.2 DORA (SaaS Security) DORA-10.1