Desktop recorder, download
Screenata

Integrations / Version control & CI

Screenata + Bitbucket

How do you collect SOC 2 and ISO 27001 evidence from Bitbucket?

Quick answer

Bitbucket is where change management gets proved, because SOC 2 CC8.1 asks you to show that a change was reviewed and authorized before it reached production, and the pull request record is what shows it. Having Bitbucket is not the control. The control is the enforced configuration, such as branch restrictions on the main branch and required approvals on pull requests, plus the record that the configuration operated across the whole audit period. Screenata runs 15 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.

Screenata connects to Bitbucket read-only and runs 15 native checks across your workspaces: branch restrictions, merge checks, and repository security settings. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls through a shared control catalog.

See how Vera works

15 native checks · read-only · signed evidence

What it proves

Bitbucket evidence, mapped to controls.

Each area below is scanned on a schedule. A finding is not a green checkmark: it is a signed artifact an auditor can verify, mapped to the exact requirement it satisfies.
Evidence area
What the checks verify
Maps to
Branch restrictions

Restriction rules on production branches, verified per repository against your change management policy.

Proof that direct pushes to production branches are prevented.

SOC 2CC8.1ISO 27001A.8.32
Merge checks

Whether merges require the checks and approvals your deployment process describes.

The review-before-deploy record auditors sample when testing change management.

SOC 2CC8.1ISO 27001A.8.32
Repository security

Repository-level security configuration across workspaces, verified against your policy baseline.

Per-repository findings showing settings match the configuration your policies describe.

SOC 2CC8.1ISO 27001A.8.9

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 Bitbucket, and why each matters.

Each row is a real native check, the framework control it produces evidence for, and the risk it closes. This is what continuous Bitbucket compliance actually looks like. Checks run on a schedule; a failing check opens a ticket and re-verifies after a human applies the fix.
Check & why it matters
Maps to

Branch Restrictions Configured

Without push and delete restrictions on the main branch, code can reach production with no enforced gate. An auditor verifies that default branches restrict pushes and deletions.

SOC 2CC8.1

Merge Approval Requirements

If pull requests do not require approval, changes merge without a second reviewer, so unauthorized code can ship. An auditor verifies that pull requests require approvals before merge.

SOC 2CC8.1

2FA Required

Without enforced two-step verification, a stolen password is enough to reach your source. An auditor verifies that the workspace requires 2FA for all members.

SOC 2CC6.1

IP Allowlist Configured

Access from any network widens the attack surface for stolen credentials. An auditor verifies that the workspace restricts access with an IP allowlist.

SOC 2CC6.1

Repositories Are Private

A public repository can expose source code and embedded secrets to anyone. An auditor verifies that repositories are private.

SOC 2CC6.1

Pipeline Secrets Secured

Secrets written inline in pipeline config leak through logs and version history. An auditor verifies that pipelines use secured variables rather than inline secrets.

SOC 2CC6.1

Project Permissions Restricted

Broad write access lets more people change production code than the process intends. An auditor verifies that projects stay private and limit write permissions to appropriate members.

SOC 2CC6.1SOC 2CC6.3

Audit Log Accessible

Without an accessible audit log, security events cannot be reviewed or investigated. An auditor verifies that the workspace audit log is available for monitoring.

SOC 2CC7.2

Force Push Disabled

Force pushing to the default branch rewrites history and can erase the record of what changed and who approved it. An auditor verifies that force push is restricted on the default branch.

SOC 2CC8.1

Build Status Required Before Merge

Merging without a passing build lets untested or failing code reach production. An auditor verifies that pull requests require passing builds before merge.

SOC 2CC8.1

Default Reviewers Configured

Without default reviewers, pull requests can go out with no one assigned to check them. An auditor verifies that repositories assign default reviewers for pull requests.

SOC 2CC8.1

Pipelines CI/CD Enabled

Without a CI pipeline, changes ship with no automated build or test gate. An auditor verifies that Bitbucket Pipelines is enabled for continuous integration.

SOC 2CC8.1

Drawn from Screenata’s Bitbucket check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.

How it connects

Read-only, revocable, yours.

You authorize a read-only connection and Screenata uses it for scheduled scans. Code is never persisted, credentials never touch the Screenata database, and the connection can be revoked from your Bitbucket settings at any time.

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.

Bitbucket FAQ

What teams ask before connecting.

Full provider list on the integrations page.
What access does Screenata need to Bitbucket?

A read-only connection that you authorize and control. Scans read repository configuration and settings; code is never persisted, and you can revoke access at any time from your Bitbucket workspace settings.

How does Bitbucket evidence map to SOC 2?

Branch restrictions and merge checks are the technical enforcement of CC8.1 change management: they prove changes are reviewed and authorized before reaching production. The scheduled scans turn that from a point-in-time screenshot into a continuous record.

What happens when a Bitbucket check fails?

Vera opens a ticket describing the failing configuration and re-verifies after a human applies the fix. Nothing in your repositories is changed by Screenata; the connection is read-only by construction.

What are the steps to implement SOC 2 with Bitbucket?

First, authorize a read-only connection covering the workspaces in scope. Second, let the first scan run so the baseline reflects how your repositories are actually configured. Third, fix what fails: configure branch restrictions so the default branch cannot be pushed to or deleted directly, require approvals on pull requests, assign default reviewers, require a passing build before merge, restrict force push, and enforce two-step verification for the workspace. 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 change management?

They pick a sample of merged changes and expect four things for each one. That a review happened before the merge, not after. That an enforced branch restriction and merge check configuration made the review mandatory rather than a convention people follow. That the approver was someone other than the author. And that the record covers the whole audit period, not a screenshot taken the week before fieldwork. Branch Restrictions Configured and Merge Approval Requirements show the enforcement, Default Reviewers Configured shows someone was always assigned to look, and Build Status Required Before Merge shows the testing gate held.

Do auditors accept evidence Screenata collects from Bitbucket?

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.

Connect and see

Fifteen minutes after connecting Bitbucket, you know your real posture.

Pricing

Related: GitHub · GitLab · Azure DevOps