Integrations / Security & monitoring
Screenata + SentryHow do you turn Sentry into SOC 2 and ISO 27001 evidence?
Quick answer
Sentry does the detecting. SOC 2 CC7.2 and the Availability criteria then ask you to prove the monitoring program around it operates, which is a different question from whether the SDK is installed. Having Sentry is not the control. The control is the enforced configuration, such as production projects reporting errors, alerts reaching someone who responds, and access to that error data restricted, plus the record that the configuration held across the whole audit period. Screenata runs native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to Sentry read-only and records error monitoring state as evidence for availability controls: that production errors are captured, surfaced, and feed your incident process. The connection turns the monitoring your system description claims into a signed, timestamped artifact an auditor can verify.
Read-only · signed evidence
What it proves
Sentry evidence, mapped to controls.
Whether the production projects your availability commitments depend on are captured in Sentry.
Proof that application errors are monitored, supporting the availability and monitoring controls your system description names.
That error signal reaches the people who respond, so monitoring connects to your incident process.
The link auditors probe between detecting a production problem and doing something about it.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on Sentry, and why each matters.
Sentry Members Have 2FA
Verifies every member account has two-factor authentication. Sentry holds stack traces and request payloads, so an account takeover exposes production error data, and an auditor checks that access requires more than a password.
Sentry Enforces 2FA or SSO
Confirms the organization requires 2FA or delegates authentication to SSO. Without an org-wide requirement, one unprotected account can reach production error data, and an auditor verifies authentication strength is enforced centrally.
Sentry Privileged Roles Limited
Checks that owner, manager, and admin roles stay within a set limit. These roles can change authentication settings and remove data-scrubbing, and over-granting them is the most common access-review finding an auditor flags.
No Stale Sentry Invitations
Verifies no invitation sits pending or expired past the window. A long-lived invite is an unclaimed credential to error data and inflates the access-review population, and an auditor checks that provisioning is closed out promptly.
Drawn from Screenata’s Sentry check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
What access does Screenata need to Sentry?
A read-scoped auth token that you create and control. Screenata uses it on a schedule and never receives write access to your organization. You can revoke the token at any time.
Does Screenata replace Sentry?
No. Sentry catches the errors; Screenata proves the monitoring exists and operates, recording it as signed evidence for the availability controls in SOC 2.
Why does error monitoring matter for SOC 2?
If your report includes the Availability criteria, auditors test whether you monitor the systems behind your commitments and respond when they degrade. Sentry state is direct evidence for the monitoring half of that test.
What are the steps to implement SOC 2 with Sentry?
First, create a read-scoped auth token and connect it. Second, let the first scan run so the baseline shows the real state of your organization rather than the state you assume. Third, fix what fails: confirm the production projects behind your availability commitments are reporting into Sentry, enforce 2FA or SSO at the organization level, get every member account onto two-factor authentication, cut owner, manager, and admin roles back to the people who need them, clear the stale and expired invitations, and point alert routing at a channel someone watches. Fourth, leave the scheduled scans running so passing results accumulate as signed evidence across the observation window, which for a Type 2 report is usually three to twelve months. Fifth, hand the evidence package to an independent auditor. The audit is a separate engagement with a licensed CPA firm, which issues the report; Screenata prepares and holds the evidence it asks for.
What evidence do auditors ask for about system monitoring?
Four things. That monitoring exists on the systems in scope, matching what your system description names rather than a subset of it. That alerts route to a human who actually responds, since an alert landing in an unwatched channel is not a control. That logs and error data are retained long enough to investigate an incident and support the audit sample. And that the configuration held across the whole audit period, not just on the day someone took the screenshot.
Do auditors accept evidence Screenata collects from Sentry?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.