Soc 2 Subservice Organization
A soc 2 subservice organization is a vendor that runs key controls for your service. Tech teams meet audit rules by checking vendor reports and logging all internal data tasks. Modern software relies on cloud hosts, external databases, and payment processors to run. When these third parties handle customer data, your auditor will review their security rules. You must know which vendors fall into this group before your audit starts. Scoping a soc 2 subservice organization for your audit Not e
GCP Organization Policies + SOC 2 Type I & Type II: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A soc 2 subservice organization is a vendor that runs key controls for your service. Tech teams meet audit rules by checking vendor reports and logging all internal data tasks.
Modern software relies on cloud hosts, external databases, and payment processors to run. When these third parties handle customer data, your auditor will review their security rules. You must know which vendors fall into this group before your audit starts.
Scoping a soc 2 subservice organization for your audit
Not every vendor you pay is a subservice provider in your audit. A vendor qualifies only if you need their controls to meet your own commitments. Cloud hosts and managed database providers almost always fit into this specific group. A team chat app or office supply vendor usually stays out of scope.
You have two ways to handle these key vendors in your audit report. The inclusive method pulls the vendor and their controls right into your own report. The carve-out method leaves the vendor out of your report scope. Most tech teams choose the carve-out method because vendors rarely share internal audit files.
Even when you carve a vendor out, your team still owns key duties. Auditors call these duties complementary subservice organization controls in the final audit document. You must read the vendor SOC 2 report each year and check their findings. You also need to set up strict login rules for their cloud tools.
Auditors ask for clear proof that you govern access to these hosted systems. They want to see how your engineers log in to cloud databases and servers. Your team must show role reviews, ticket approvals, and detailed logs of every session. These exact same records also help teams prepare for HIPAA, GDPR, PCI DSS, and SOX.
Why login setup and reviews need runtime logs and masking
Setting up single sign-on and quarterly role reviews is a great first step. Still, a role chart only shows who could log in to a vendor system. It does not show what an engineer actually ran inside that production database. Auditors now ask for deeper proof of how teams use their broad admin roles.
GCP Organization Policies + SOC 2 Type I & Type II: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared database accounts create a huge blind spot during a security audit. Five developers might use the same admin password to fix a live bug. When an auditor asks who changed a table, the database log shows one shared name. Tying every single query back to a human identity solves this audit problem.
Command and query logs give your security team the real story of every session. Instead of guessing what happened during an outage, you can read the exact commands. You can show the auditor who approved a risky command before it ever ran. This turns a stressful audit check into a quick file export.
Data privacy rules also matter when engineers read live tables on vendor systems. Production tables often hold sensitive emails, phone numbers, card numbers, and national IDs. Response masking rewrites matched fields in results before they reach the engineer screen. Your team can fix live bugs while keeping sensitive customer fields masked by default.
How to prepare vendor evidence before the audit window
Start by listing every third party that stores or processes your customer data. Collect their latest audit reports and note the exact dates they cover. If a report ends months before your audit, ask the vendor for a bridge letter. A bridge letter states that their security controls did not change since the last check.
Next, map your own access rules to the duties listed in their report. Verify that every human user logs in with their own work identity. Check that you revoke roles the same day an employee leaves your company. Pull a clean sample of command logs to show your rules work every day.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between a vendor and a subservice organization?
A normal vendor provides general tools that do not touch core service commitments. A subservice provider runs key parts of your system that affect your security controls.
Should our team use the carve-out or inclusive audit method?
Most companies use the carve-out method for public cloud and database providers. The inclusive method requires the vendor to sign off and join your audit directly.
What happens if a key vendor does not have a SOC 2 report?
You must test their security yourself or show your own controls cover the risk. Many teams accept an ISO 27001 certificate along with a detailed security review.