# Compliance & Security

Buzzy gives app builders platform-level security controls for protecting data. These controls can help support compliance programs such as SOC 2, GDPR, HIPAA, and internal security policies, but they do not make an app compliant by themselves.

Compliance depends on the complete system: app configuration, deployment controls, policies, procedures, contracts, staff training, incident response, backups, monitoring, and legal review.

{% hint style="warning" %}
This documentation explains Buzzy capabilities that can support compliance and security requirements. It is not legal, privacy, or compliance advice.
{% endhint %}

## Deployment and Data Residency Options

Private Data controls protect values before they leave the Buzzy server, but compliance also depends on where that server, database, storage, backups, and logs run.

Buzzy supports deployment models that can help organizations meet data residency, isolation, and operational control requirements:

* **Single-tenant Buzzy Deployments**: run apps on a dedicated Buzzy deployment with its own URL, database cluster, storage, and service endpoints. You can choose an available deployment region for the database cluster and deployment. See [Create and manage Deployments](/working-with-buzzy/buzzy-deployment-and-app-stores/create-and-manage-deployments.md).
* **Enterprise deployments**: run Buzzy on your own infrastructure, including your own cloud environment or on-premise infrastructure, when your organization needs deeper control over network, hosting, security, or operational requirements. See [Introduction to deployment](/advanced-deployment-settings/installation/deployment/introduction-to-deployment.md).

Plan availability and commercial options are listed on the [Buzzy pricing page](https://www.buzzy.buzz/pricing#deployment). Use this deployment choice alongside app-level Private Data, row access, field access, audit retention, and organizational security processes.

## What Buzzy Provides

Buzzy helps app builders configure security without writing custom authorization code.

Core capabilities include:

* app privacy and role controls
* row-level access using creators, Viewers, Team Viewers, teams, and organizations
* field-level view and edit controls
* Private Data classification and redaction
* encryption at rest for sensitive Private Data
* audited reveal of Sensitive Private Data
* server-shaped REST API and MCP output
* attachment gating for Private Data files and images
* configurable audit retention

The key design principle is server-side enforcement. Data that a user should not access should not be sent to that user.

## Capability Mapping

| Control need                 | Buzzy capability                                            | App-builder responsibility                                                                          |
| ---------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Access control               | App privacy, roles, row access, Field view/edit             | Choose restrictive defaults and test with different users                                           |
| Least privilege              | Field view/edit and team/org viewer policies                | Give users access only to the rows and fields required for their work                               |
| Data minimization            | Private Data classification and server-side output shaping  | Mark fields correctly and avoid exposing data in unnecessary screens, APIs, prompts, or exports     |
| Encryption at rest           | Sensitive Private Data encryption                           | Configure encryption keys and run repair when settings change                                       |
| Audit evidence               | Private Data reveal audit trail                             | Review row audit trails from Workspace Data and define operational review procedures                |
| API governance               | REST responses follow row, field, and Private Data rules    | Authenticate integrations as the correct user and avoid over-broad service accounts                 |
| MCP governance               | MCP tools follow the same data shaping rules                | Enable MCP only for apps and users that should expose data to AI assistants                         |
| Retention                    | TTL-based Private Data audit retention                      | Set retention to match organizational and legal requirements                                        |
| Data residency and isolation | Single-tenant Deployments and Enterprise deployment options | Choose the deployment model, region, infrastructure, and contracts that match the compliance target |

## Recommended Security Model

Use these layers together:

1. Make the app private unless it truly needs public access.
2. Use Organizations and Teams for customer, department, or tenant boundaries.
3. Configure datatable "Who can view" so users only fetch rows they should see.
4. Use Viewers or Team Viewers for row-specific sharing.
5. Use Field view/edit for least privilege inside each row.
6. Mark personal, sensitive, regulated, or confidential fields as Private Data.
7. Keep searchable/sortable operational metadata separate from encrypted Private Data.
8. Test runtime, workspace, REST API, and MCP access as multiple users.
9. Review audit trail entries for Sensitive Private Data reveals.

## Private Data for Compliance-Ready Apps

Private Data is the main Buzzy capability for reducing accidental exposure of sensitive fields.

* **Basic Private Data** is masked or redacted by the server before output.
* **Sensitive Private Data** is hidden by default, can be revealed only by permitted users, and records audit entries.
* Sensitive Private Data is encrypted at rest.
* Private Data file and image fields hide attachment metadata and signed URLs from denied users.

Use Basic Private Data for personal contact or identifier fields. Use Sensitive Private Data for fields that would create higher risk if exposed, such as health details, financial information, government identifiers, or confidential notes.

See [Private Data](/the-building-blocks/datatables-fields-and-data/private-data.md) for configuration steps.

## Secure Review Workflows

Compliance-ready apps often need more than a single "private" switch. Use Buzzy row access, field access, teams, organizations, and Private Data together.

For example:

* a submitter creates a case and sees only safe status fields
* the Legal Reviewers team can view and edit legal analysis fields
* the Compliance Reviewers team can view and edit risk and evidence fields
* managers can approve outcomes without seeing every sensitive detail
* admins can inspect Private Data audit entries from Workspace Data

Use row Viewers and Team Viewers to decide who can open each record. Use Field view and Field edit to decide which fields those users can see or change. Use Private Data for fields that need server-side masking, hidden-by-default reveal, encryption, file URL gating, or audit evidence.

See [Secure and Compliant Workflow App](/the-ultimate-guide-for-vibe-coding-an-application-with-ai/building-examples/secure-compliance-workflow.md) for a complete app-builder example.

## API, MCP, AI, and Export Considerations

Compliance-oriented apps need the same protection outside the visual app runtime.

Buzzy applies Private Data output shaping to normal outbound paths, including REST API responses, MCP tools, exports, generated previews, and AI prompt/context builders.

Design guidance:

* Do not assume an integration should receive all row fields.
* Authenticate REST and MCP calls as the actual user or a narrowly scoped integration user.
* Avoid using broad Admin accounts for integrations unless the integration genuinely needs Admin access.
* Do not place Sensitive Private Data in search, sort, or vector fields.
* Test denied users through REST and MCP, not only through the browser UI.

## Example Compliance-Oriented Patterns

### Healthcare Notes

* Restrict patient note rows to clinicians and care teams.
* Mark patient identifiers as Basic Private Data.
* Mark clinical observations and health details as Sensitive Private Data.
* Require purpose text for reveals.
* Review audit logs for reveal activity.

### Customer Data Platform

* Use Organizations to separate customers.
* Use Team Viewers for account teams.
* Mark customer emails and phone numbers as Basic Private Data.
* Keep customer status, lifecycle stage, and account owner as non-private fields for reporting.

### HR Case Management

* Restrict rows by creator, HR team, or assigned case team.
* Mark employee contact details as Basic Private Data.
* Mark salary, leave, performance, and medical details as Sensitive Private Data.
* Use Field edit so only HR can update protected fields.

## Compliance Notes by Framework

### SOC 2

Buzzy controls can support access control, logical access review, audit evidence, change control, and data protection requirements. Your organization still needs operational evidence, review procedures, incident response, vendor management, and deployment controls.

### GDPR

Buzzy controls can support data minimization, access restriction, auditability, and protection of personal information. Your organization still needs a lawful basis, notices, data subject request processes, retention policy, and processor/controller agreements.

### HIPAA

Buzzy controls can support technical safeguards such as access control, audit controls, encryption, and transmission security. HIPAA use also requires appropriate deployment, policies, business associate agreements, risk analysis, and administrative safeguards.

For regulated workloads, review deployment model and region choices early. Private Data is one application-layer control; single-tenant or Enterprise deployment choices determine where the supporting infrastructure, database, object storage, and operational controls run.

## Security Checklist

* [ ] App privacy is appropriate for the data being stored.
* [ ] Datatable row access is restrictive by default.
* [ ] Viewers or Team Viewers are used for row-specific sharing.
* [ ] Field view and edit policies follow least privilege.
* [ ] Field edit is not broader than field view.
* [ ] Private Data fields are classified as Basic or Sensitive where needed.
* [ ] Sensitive Private Data has a clear purpose.
* [ ] Private Data file/image fields are tested with denied users.
* [ ] Search, sort, export, REST API, MCP, and AI paths have been tested.
* [ ] Audit retention is configured for the deployment.
* [ ] Datatable repair has been run after changing classification or encryption settings.
* [ ] The app security model is documented for reviewers and operators.

## Related Docs

* [Security and Access Control](/the-building-blocks/datatables-fields-and-data/security-and-access-control.md)
* [Private Data](/the-building-blocks/datatables-fields-and-data/private-data.md)
* [REST API microappdata](/rest-api/buzzy-rest-api/rest-api/microapp-data-operations/microappdata.md)
* [MicroAppChild API](/rest-api/buzzy-rest-api/rest-api/microapp-data-operations/microappchild.md)
* [Model Context Protocol](/the-building-blocks/mcp.md)
* [Create and manage Deployments](/working-with-buzzy/buzzy-deployment-and-app-stores/create-and-manage-deployments.md)
* [Enterprise deployment](/advanced-deployment-settings/installation/deployment/introduction-to-deployment.md)
* [Buzzy pricing](https://www.buzzy.buzz/pricing#deployment)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.buzzy.buzz/the-ultimate-guide-for-vibe-coding-an-application-with-ai/best-practices/compliance-security.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.