# Security, privacy, and governance

Product design

This page describes the product model and requirements. Examples illustrate the model, not a guaranteed API or completed feature. Check the [application contracts](/stormtrust/apps/) and [dataset inventory](/stormtrust/product/platform-and-data/datasets-and-source-contracts/) for implemented scope. Use [operations guides](/stormtrust/engineering/operations/) for runnable procedures.

StormTrust follows least privilege, explicit tenant context, defense in depth, immutable audits for consequential actions, secret isolation, signed integration traffic, and minimal data exposure.

## Authentication

Human users receive host-only secure sessions. API clients receive separately managed credentials. The public gateway validates identity before forwarding protected requests. Authentication does not imply authorization.

`auth.stormtrust.net` owns identity proof, verified email, recovery, and session state. It returns identity claims through a private service binding and does not assign StormTrust product roles.

## Authorization

Policies use explicit capabilities:

```txt
storms.view
storms.review
properties.view
properties.enrich
contacts.view
contacts.export
campaigns.view
campaigns.create
campaigns.approve
reports.create
reports.certify
admin.users
admin.integrations
```

The gateway enforces coarse route entry through platform roles and permissions. Each origin service still checks tenant scope, object ownership, and the requested action. Client-supplied identity headers never establish authorization. Cookie-authenticated state changes must also originate from the same application origin.

A verified account receives the baseline `member` role once. Operator and administrator roles require an explicit trusted assignment. Revoking a role is durable and is not undone by a later sign-in.

## Tenant isolation

Every tenant-owned query is scoped. A client-provided tenant ID is not sufficient authorization.

## Data classification

| Class       | Examples                         |
| ----------- | -------------------------------- |
| Public      | Public storm page data           |
| Internal    | Derived event diagnostics        |
| Tenant      | Action plans and assignments     |
| Sensitive   | Contact information              |
| Restricted  | Secrets and provider credentials |
| Evidentiary | Preserved evidence artifacts     |

## Contact data

Contact-data audits identify who viewed or exported the data, the purpose, source, license, and campaign use.

## Consent and suppression

Consent records include subject, channel, purpose, source, timestamp, evidence, and expiration when applicable. Suppression overrides campaign convenience.

## Data licensing

StormTrust preserves provider restrictions. Data may be viewable but not redistributable, purpose-limited, retention-limited, or unavailable to certain tenants and jurisdictions. The product enforces restrictions structurally when practical.

## Secrets

Secrets do not enter source repositories. StormTrust separates application configuration, tenant integration credentials, infrastructure credentials, and API keys.

## Webhook security

Webhook delivery supports HTTPS, signatures, timestamps, replay resistance, rotation, and retry IDs. Inbound webhooks are idempotent.

## Audit logs

Audits cover security changes, roles, contact access, exports, evidence review, report certification, campaign approval, integration credentials, suppression, and destructive operations.

## Incident response

Incident response covers detection, containment, evidence preservation, tenant impact analysis, remediation, required notification, retrospective review, and control improvement.