SOC 2 policies for Bitbucket teams
Bitbucket is where code is reviewed and released, so it appears in the policies about change management, secure development, vulnerability handling, access to source code and what gets logged.
Source control and CI · Referenced by 5 of 22 policies · Generator preset available
The 5 policies that reference Bitbucket
With Bitbucket in your intake, these policies name it in their scope, roles and procedures. The other 17 policies in the set apply to your company regardless of tooling; the template index lists all 22.
- P03 Access Control Policy: Defines how access to systems and data is requested, approved, provisioned, reviewed and removed.
- P09 Change Management Policy: Requires that every change to production code, infrastructure and security-relevant configuration is proposed, reviewed, tested, approved and deployed through a controlled and traceable process.
- P10 Secure Software Development Policy: Embeds security into how the product is designed, built, tested, dependency-managed and released so that vulnerabilities are prevented or found before they reach customers.
- P11 Vulnerability and Patch Management Policy: Establishes how vulnerabilities in code, dependencies, infrastructure, endpoints and vendor services are discovered, rated, remediated within defined timeframes and verified.
- P12 Logging and Monitoring Policy: Defines which security-relevant events are logged across the product, cloud and corporate systems, how logs are protected and retained, and how alerts are triaged and acted on.
What the Audit Kit writes for Bitbucket
The free generator fills in names. The Audit Kit goes further: Claude rewrites section 4 (Policy Statements) and section 5 (Procedures) of each policy using your full intake, so the text describes Bitbucket the way you actually run it. The statements below are examples of that output for Bitbucket; your own answers produce different text, and every statement should be checked against your configuration before management adopts it.
P03 Access Control Policy
The Bitbucket Cloud workspace administrator permission is held by no more than two named people, and repository access is granted through user groups assigned at the project level with the least permission needed (Read, Write or Admin) rather than to individuals. Two-step verification is enforced in the workspace settings where the workspace is on Bitbucket Premium, single sign-on through the identity provider is enforced with an Atlassian Guard authentication policy where the company subscribes to Atlassian Guard, and workspace members and group memberships are reconciled against the identity provider at each quarterly access review.
Bitbucket Pipelines authenticate to the cloud provider with OpenID Connect and short-lived credentials, so no long-lived cloud access keys are stored as repository, workspace or deployment variables, and any variable that must hold a secret is a secured variable. Automation that calls Bitbucket uses repository or project access tokens with only the scopes it needs, never a person's credentials, and each token is recorded with its owner and purpose and is rotated at least annually.
P09 Change Management Policy
The main branch of every deployable repository has branch restrictions that allow no direct pushes, prevent rewriting history and prevent deletion, so changes reach it only through a pull request. Merge checks require at least one approval from someone other than the author, a successful Pipelines build on the last commit, no unresolved pull request tasks and no outstanding change requests. Where the plan supports enforced merge checks (Bitbucket Premium), merges are blocked until every check passes; otherwise the monthly change review confirms that no pull request was merged with a failed check.
P10 Secure Software Development Policy
Every pull request runs static analysis, dependency scanning and secret detection as steps in Bitbucket Pipelines, and the results are attached to the pull request as Code Insights reports and annotations. A scan step fails when it finds a new Critical or High issue, and such a pull request is merged only after the issue is fixed or the Security Owner approves a recorded exception.
P11 Vulnerability and Patch Management Policy
Findings from the dependency and container image scan steps in Bitbucket Pipelines are recorded in the vulnerability register. Critical findings are remediated within seven days and High within thirty days, every dismissed finding carries a recorded reason, and a scheduled pipeline rescans the default branch of every deployable repository weekly so that newly published vulnerabilities in existing dependencies are found between changes.
P12 Logging and Monitoring Policy
Where the workspace is on Bitbucket Premium, the workspace audit log is exported to the central logging tool, and the Security Owner reviews it weekly for changes to branch restrictions, merge checks, workspace and group permissions, access tokens and Pipelines variables that do not match an approved ticket. On plans without the audit log, those settings are read through the Bitbucket API at each quarterly access review and compared with the previous export.
How to use this page
- Open the generator with the Bitbucket preset and answer the remaining questions: company, product, headcount, other tools, data types, owners, scope and review cadence.
- Download the 22 policies as Markdown. Read the sections that mention Bitbucket with the admin console open and fix anything that is not true of your setup.
- Optionally buy the Audit Kit to have sections 4 and 5 tailored to Bitbucket and the rest of your stack, and to get Word documents, the TSC crosswalk, an evidence checklist, acknowledgment forms and a review calendar in one ZIP built on your machine.
- Have management approve the policies, collect acknowledgments, and start producing the evidence the procedures describe. The CPA firm performs the examination.
Other tools
Cloud platforms: AWS, Google Cloud, Microsoft Azure, Vercel, Cloudflare, Fly.io, Hetzner
Source control and CI: GitHub, GitLab
Identity providers: Google Workspace, Okta, Microsoft 365, JumpCloud
Vendors and subprocessors: Supabase, Clerk
Frequently asked questions
- Does Bitbucket's own security assurance cover our SOC 2?
- No. Whatever independent assurance Bitbucket provides, such as a SOC 2 report or an ISO 27001 certificate, covers the controls Bitbucket operates for its own platform. Your examination covers how your company configures and uses Bitbucket: who has access, how it is authenticated, what is logged and how data in it is protected. Auditors read the vendor's assurance to decide what they can rely on, and the Vendor and Third-Party Risk Management Policy tells you to obtain it at onboarding and annually, and to send a security questionnaire where gaps remain.
- What does the generator pre-fill when I arrive from this page?
- The link on this page opens the generator with a preset that sets the source control to Bitbucket. The other answers (company, product, headcount, owners, data types, scope and review cadence) are yours to fill in. The policies render in your browser as Markdown; nothing is sent to a server and there is no signup.
- Which policies change when I add Bitbucket to my answers?
- 5 policies name Bitbucket once it is in the intake: Access Control Policy, Change Management Policy, Secure Software Development Policy, Vulnerability and Patch Management Policy, Logging and Monitoring Policy. The free generator names it in scope, roles and procedures; the Audit Kit ($59 one-time) rewrites sections 4 and 5 of each policy with statements specific to how Bitbucket is configured, like the examples on this page. Refunds are available within 14 days on request.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.