How we handle data and code we touch.

mcintoshsystems.com is a static build produced by Astro, served from a DigitalOcean VPS, and proxied through Cloudflare (TLS termination, CDN, WAF). There is no application server, no user-account system, no login, no API endpoint, no database. The attack surface of the site is roughly: nginx serving static files, Cloudflare's edge, the DNS record, and the HTML/CSS/JS bundle.

The site sets no cookies of its own. It runs no inbound forms. Contact happens through email. The smallest surface area we could reasonably ship.

Every engagement deploys inside the client's own tenant. The pattern is the same across engagements regardless of cloud provider:

• Source code lives in a Git repository owned by the client (typically Azure DevOps or GitHub on the client's organisation). We are collaborators for the life of the engagement and removed at the end.
• CI/CD runs on the client's pipeline, against the client's subscription, using deployment credentials that belong to the client.
• Production secrets resolve through the client's secret manager (Azure Key Vault, AWS Secrets Manager, etc.) at runtime. Our code never holds a secret value at rest.
• Authentication validates against the client's identity provider. Identity, group membership, and conditional-access policies stay where they already live.
• Database and storage sit in client-controlled infrastructure. We do not host client data.
• Team members are granted access to production only where the workflow requires it, scoped through the client's IAM, read-only by default and time-bounded where the client's policy supports it.

There is no standing access from McIntosh Systems infrastructure back into client environments. No site-to-site tunnel. No service principal that lives on our laptops with production-write rights. An engagement ends by the client revoking three or four role assignments. The system keeps running after the access ends.

If you have found a security issue with this site, with code we have published, or with a system we operate on a client's behalf, write to us. Plain prose is fine. Include reproduction steps and the impact you observed. We will reply.

We triage on receipt and acknowledge inside two business days. We do not run a paid bug bounty programme. We do credit reporters publicly once an issue is fixed if the reporter wants the credit.

Those certifications attest to controls a vendor operates on the data it holds. The engagement model is structured so we do not hold the data. Client production data sits in the client's tenant, behind the client's IAM, encrypted with the client's keys. We pass through the data without ever holding it.

That is a deliberate choice, not a missing badge. Building a SOC 2 boundary around a firm with no shared multi-tenant infrastructure would describe a boundary that does not contain the work. The client's existing certifications, applied to the client's tenant, are the relevant attestation surface.

Two cases where this doesn't fit, and what we do instead:

• If your procurement process treats SOC 2 / ISO 27001 as a hard gate for any consulting engagement regardless of where data sits, we can route the engagement through a partner firm that holds the certification, with McIntosh Systems sub-contracting.
• If a specific scope inside the engagement would require touching a certified data path, we scope the work so we do not touch it — the client's team handles that step, and we hand off cleanly at the boundary.

Either way, we would rather have the conversation than ship a checkbox that misrepresents how the firm operates.