Security Architecture
Access controls, tenant identifiers, data stores, dashboards, APIs, reports, retrieval sources, and automation preserve customer boundaries and prevent unauthorized cross-customer access.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
A valid user, service, job, report, and support workflow stays inside its authorized customer boundary and cannot read or alter another customer’s data by changing an identifier or execution path.
First SOC 2 program
Choose and document one tenant-isolation model, derive tenant context from the authenticated server-side identity, enforce it in shared data-access code, and write cross-customer tests for APIs, object downloads, reports, and background jobs before adding more product paths.
As the company scales
Add independent enforcement such as database row policies or service-level authorization, carry trusted tenant context through asynchronous messaging and analytics, test every new data path automatically, and monitor sensitive support overrides and boundary failures.
Map how customer identity and data move through interactive requests, storage, search, cache, exports, analytics, support access, and asynchronous processing, including every place tenant context is created or transformed.
You should end up with: A tenant-boundary diagram and data-path inventory that engineering owners can validate.
Bind the authenticated identity to its authorized customer scope on the server and prevent browser-supplied identifiers from independently selecting a tenant.
You should end up with: A documented identity-to-tenant resolution flow with representative configuration or code references.
Apply tenant conditions to database queries, object paths, API policies, caches, search filters, reports, jobs, and integrations, and constrain support overrides to explicit, logged workflows.
You should end up with: An enforcement matrix linking each data path to its tenant-scoping mechanism.
Use two realistic customer contexts to attempt direct-object substitution, bulk export, object download, search, job replay, and administrative access across the boundary.
You should end up with: Repeatable negative-test results showing denied cross-customer requests for each critical path.
Log actor, tenant, target object, decision, and support override where practical, then investigate authorization failures or mismatched tenant context that could indicate a defect or attack.
You should end up with: Representative boundary events, alert logic, and completed investigation records.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
The approved design identifies the trusted source of tenant context and the required isolation mechanism for APIs, storage, reports, jobs, support access, and other customer-data paths.
Include this context
Tenant-context source
Include this context
Actors and services
Include this context
Data stores and paths
Include this context
Enforcement points
Include this context
Support override path
Include this context
Owner and version
Weak evidence to avoid
A high-level multi-tenant label with no trusted context source, enforcement points, asynchronous paths, support access, or version owner.
Confirm what the record proves
The current deployed architecture shows where customer context and data pass through services, stores, queues, caches, search, analytics, exports, and administrative components.
Include this context
Components and environments
Include this context
Customer-data flows
Include this context
Trust boundaries
Include this context
Stores and asynchronous paths
Include this context
External integrations
Include this context
Review date
Weak evidence to avoid
A marketing architecture picture that omits tenant context, data stores, background jobs, reporting paths, environment, and last review date.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
A valid identity from one customer is denied when it attempts to use another customer’s object identifier, API path, storage object, job, or administrative operation.
Include this context
Test run ID
Include this context
Source and target tenant
Include this context
Identity and role
Include this context
Path or object tested
Include this context
Expected and actual result
Include this context
Failure and retest status
Weak evidence to avoid
A passing login test with one tenant that never exercises a valid cross-customer identity, direct object, export, job, or support path.
Confirm what the record proves
Customer-facing reports and exports apply tenant filtering to complete output and were checked for cross-customer rows, objects, metadata, and cached results.
Include this context
Report or export ID
Include this context
Tenant and role
Include this context
Data scope
Include this context
Validation method
Include this context
Expected and actual result
Include this context
Reviewer and date
Weak evidence to avoid
A screenshot of one correctly filtered report with no export population, second-tenant challenge, validation method, or reviewer.
Type 1
As of the selected date, retain the current tenant-boundary model and deployed architecture, current enforcement configuration for representative paths, and the latest successful cross-customer access and report or export validations.
Type 2
Include every material change to tenant-context derivation, authorization enforcement, customer data paths, support overrides, reporting, exports, storage, or asynchronous processing; every required cross-customer test run triggered by those changes or the defined schedule; and every governed support override during the review period.
Reconcile deployed services, storage locations, queues, reports, exports, search indexes, caches, and support functions to the tenant-boundary path inventory, then reconcile every in-scope change and scheduled test obligation to delivery and test-run histories.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: A valid user, service, job, report, and support workflow stays inside its authorized customer boundary and cannot read or alter another customer’s data by changing an identifier or execution path.
Compare the documented owner with the intended role (Infrastructure / Security Operations / IT), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.
Reconcile deployed services, storage locations, queues, reports, exports, search indexes, caches, and support functions to the tenant-boundary path inventory, then reconcile every in-scope change and scheduled test obligation to delivery and test-run histories.
As of the selected date, retain the current tenant-boundary model and deployed architecture, current enforcement configuration for representative paths, and the latest successful cross-customer access and report or export validations.
Include every material change to tenant-context derivation, authorization enforcement, customer data paths, support overrides, reporting, exports, storage, or asynchronous processing; every required cross-customer test run triggered by those changes or the defined schedule; and every governed support override during the review period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates The approved design identifies the trusted source of tenant context and the required isolation mechanism for APIs, storage, reports, jobs, support access, and other customer-data paths.
For each selected record, confirm it demonstrates The current deployed architecture shows where customer context and data pass through services, stores, queues, caches, search, analytics, exports, and administrative components.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates A valid identity from one customer is denied when it attempts to use another customer’s object identifier, API path, storage object, job, or administrative operation.
For each selected record, confirm it demonstrates Customer-facing reports and exports apply tenant filtering to complete output and were checked for cross-customer rows, objects, metadata, and cached results.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.