Information Security Policy

Ziggi's Salisbury #153 · Draft v0.1 — pending owner review

Draft. Prepared for owner review and not yet in effect. The security contact and effective date are pending sign-off.

1. Purpose and scope

This policy states how Ziggi's Salisbury #153 protects the systems and data of its operating and property entities. It covers this application, the Azure resources that host it, the source repository, and the workstations of anyone with administrative access. It applies to every person with an account, including contractors. It is owned by the business owner, who is accountable for the controls below.

We hold no third-party security certification and make no claim to one. This document describes the controls we operate and the commitments we hold ourselves to.

2. Access control

Unique accounts only. Every user has their own named account. Shared or generic logins are prohibited, and no account is shared between people.
Approval workflow. A new account has no access by default. An authenticated user without an approval is held at a pending-approval screen and can reach no data until an administrator approves them.
Role-based, least privilege. Authorization is enforced by role and permission policies. Finance, payroll, and administrative surfaces require an elevated role; users are granted the least privilege their job needs.
Two-factor authentication is required for privileged access. An administrator or editor signing in with a password must enroll a two-factor authenticator before reaching any data surface; the gate is enforced in middleware on every request and returns a hard failure to API callers rather than a redirect. Federated sign-in is not exempt, because the identity provider's assertion does not prove that a second factor was used. A "remember this machine" trust expires after 48 hours of disuse and in all cases 7 days after it was first issued.
Azure control plane. Access to the Azure subscription is role-based and requires multi-factor authentication. The application itself holds only the minimum resource roles it needs.
Review and revocation. Access is reviewed at least annually and on any role change. Accounts are disabled promptly when a person leaves or no longer needs access.

3. Credential and secret management

No secrets in source or configuration files. Secrets resolve at runtime from Azure Key Vault or from an encrypted secret store in the database. Committing a secret is a defect to be fixed and rotated, not an accepted practice.
Managed identities. The application authenticates to Azure SQL, Key Vault, and Blob Storage using its platform-managed identity. There are no embedded cloud credentials.
Encrypted integration credentials. Third-party keys entered by an administrator (for example the bank-feed and accounting integrations) are encrypted before storage. Sensitive tokens — including the bank-feed access token — are encrypted under dedicated purpose-scoped keys, with the key ring itself protected by a key held in Azure Key Vault.
Rotation. Integration credentials are rotated when a person with access to them leaves, on any suspected exposure, and otherwise at least annually.
No credential capture. The application never asks for, receives, or stores a user's online banking credentials; the bank connection is completed entirely inside the provider's own hosted flow.

4. Encryption

In transit. All traffic is served over HTTPS. The platform enforces a minimum of TLS 1.2, the application issues HTTP Strict Transport Security and redirects plain HTTP to HTTPS in production, and all outbound calls to processors use TLS.
At rest. The database is encrypted at rest with Azure SQL Transparent Data Encryption. Blob storage is encrypted at rest by the platform.
Field-level. Sensitive tokens and secrets are additionally encrypted at the column level, so they are unreadable even to someone holding a database copy without the key-vault key.
Masking. Bank account numbers are not stored; only a masked last four digits is retained and displayed. Sensitive values are never written to application logs.

5. Change management

All changes are made in source control; the repository history is the record of what changed, when, and by whom.
Changes are reviewed before release, and the automated test suite is run against them. A change that fails review or tests is not released.
Architectural decisions and the work backlog are recorded in the project tracker, so a change can be traced to the decision behind it.
Releases are deployed from the reviewed source by a repeatable publish-and-deploy procedure — never by editing files on a running server.
Database schema changes ship as versioned migrations applied as part of the release.
Every data change made through the application is written to an audit log recording the acting user, the record, the before and after values, and the timestamp.

6. Vulnerability and patch management

This section is the standard we hold ourselves to and the authority for the cadence and service levels below. Dependency scanning is implemented; the cloud and endpoint posture items are commitments being enabled, not controls already fully in place.

Dependency scanning. An automated scan of the solution's package dependencies, including transitive dependencies, runs on a weekly schedule against the main branch. Extending it to run on every change is planned.
Failure gate. A finding rated High or Critical fails the scan; the affected dependency is not carried into a release until the finding is remediated or a documented, time-boxed exception is recorded by the owner.
Patch service levels. Critical: remediate within 7 days of confirmation. High: 30 days. Medium: 90 days. Low: at the next convenient release.
Monthly review. Open findings, their age against the service levels above, and any exceptions are reviewed monthly by the owner.
Cloud and endpoint posture. Cloud workload protection on the subscription and endpoint protection on machines with administrative access are to be enabled and kept updating, with alerts routed to the security contact below.
Platform patching. The application runs on a managed platform; the operating system and runtime are patched by the cloud provider. Framework and library versions are updated on the cadence above.

7. Incident response

Detect. Application and platform logs, the audit log, alerting on failed authentication and authorization, and integration failure reports are the primary signals. Anyone who suspects an incident reports it to the security contact immediately.
Contain. First actions are to revoke or rotate the affected credential, disable the affected account, and — for a suspected bank-feed compromise — delete the stored access token so the connection to the institution ends.
Assess and record. We establish what data was involved, over what period, and for whom, using the audit log and platform logs, and record a written timeline.
Notify. The owner is notified without delay. Affected individuals, affected processors — including the bank-data provider where its data is involved — and any regulator or institution owed notice are informed promptly and in any event within the timeframe the applicable law requires.
Recover and learn. Service is restored from a known-good state, and every incident produces a written corrective action with an owner and a date.

8. Vendor and processor management

We keep a current list of the processors that hold or handle our data — it is published in the Privacy Policy and is the authoritative list. Before a new processor is connected we confirm what data it will receive, the purpose, and its published security and privacy terms; the owner approves the addition. Access to each processor is by least-privilege credentials held in the encrypted secret store. The list is reviewed at least annually, and before enabling any new Plaid product or adding a processor.

9. Data retention, deletion, and backups

Retention windows per class of record, the deletion process, and backup expiry are defined in the Data Retention & Deletion Policy. Backups are the platform's automated database backups, restricted to the same identities as the database itself.

10. Personnel and workstations

Access is granted on a business need and removed when that need ends.
Anyone with administrative access keeps their operating system and browser current, uses full-disk encryption and a screen lock, and runs endpoint protection.
Credentials are not shared, reused across systems, or stored in plain text.
Company data is not copied to personal accounts or unmanaged storage.

11. Governance and review

This policy is owned by the business owner and reviewed at least annually, and before enabling any new Plaid product or adding a processor. It is also reviewed after any material incident or architecture change. Each review confirms the controls above still match what the system actually does; where they do not, either the system or this document is corrected — a control stated here that is not real is treated as a defect.

12. Security contact

Report a suspected vulnerability or incident to [OWNER TO SET — monitored security alias, e.g. security@example.com]. We acknowledge reports promptly and will keep a reporter informed of remediation.

Draft v0.1 — pending owner review · Privacy Policy · Data Retention & Deletion Policy · Terms & Conditions