Security
Last updated
This page describes the controls that protect the Brandmasters GTM platform, operated by Brandmasters Media. It is written for the person doing a vendor review, so it says what is true rather than what sounds reassuring.
Certifications: where we actually stand
We do not currently hold SOC 2 Type II or ISO/IEC 27001 certification.
We would rather say so plainly than imply otherwise. If a certification is a requirement for your procurement process, tell us at support@brandmastersmedia.com and we will tell you honestly whether and when we can meet it. The controls below are real and in place today; they are simply not third-party audited.
Access control
- Sign-in requires a password and a second factor. Backup codes are available and are stored hashed.
- Sessions are carried in a cryptographically signed cookie that cannot be altered by the holder, and the signature is verified on every protected request.
- Roles are separated: an operator and a client user reach different parts of the application, and the separation is enforced at the request boundary, not in the interface.
- Credentials are never shared between people. Each person gets their own account.
- Passwords are stored hashed. We cannot see yours.
Protecting data
- Traffic is served over HTTPS with certificates renewed automatically.
- Secrets live outside the codebase in environment configuration and a password manager. A commit hook blocks any secret-shaped string from entering version control, and it has been in place since before the platform held real data.
- The database is a managed Postgres instance with daily provider backups plus our own nightly encrypted dump, retained on a rolling 30-day window.
- Restores are drilled into a staging environment, because an untested backup is not a backup.
Isolation
Each client workspace is configured separately during onboarding, from that client's own ideal customer profile, offer and voice. Application and worker processes run in separate containers with memory limits, so a fault in one cannot starve the other.
The audit trail
Every action is recorded from the first signal to the last send: which account surfaced and why, the score it received and the reasons, every draft, who approved it, when it went, and what came back. This is a product feature and it cannot be switched off. It is what lets you reconstruct any outreach decision months later.
Monitoring and recovery
- A health endpoint reports the database, the background worker, the job queue and the running version, and returns an error status when any of them is unhealthy, so an uptime monitor alerts on a silent failure rather than only on a dead website.
- The worker writes a heartbeat. If it dies, the jobs it held are returned to the queue rather than lost, and containers restart automatically.
- Jobs retry with backoff, and budget caps park work instead of overspending.
- Failures raise alerts to our operations channel.
How changes reach production
This is the part most security questionnaires miss, and it is where most incidents actually come from.
- Nothing is edited on a live server. Every change is a commit.
- Every commit is checked on a staging environment before it can ship: type checking, linting, the full test suite, a production build, database migrations, a health check and an automated browser pass.
- The button that promotes a build to production is enabled only when every required check passed for that exact commit. A person cannot override a failed check.
- Production runs the identical build that staging tested. Nothing is rebuilt on the way.
- A verified database backup is taken before every release.
- If the new version does not report itself healthy, the previous one is restored automatically. A manual rollback takes seconds.
- Database migrations are additive, so rolling back code never strands the data.
What the engine will not do
- No LinkedIn login, no LinkedIn cookies, no browser extensions and no scraping tools. The Platform is built so this is not an option.
- No message is sent and no money is spent without a human approval. The approval step cannot be automated away.
- An email address that cannot be verified is never sent to.
Responsible disclosure
If you believe you have found a vulnerability, email support@brandmastersmedia.com with enough detail to reproduce it. We will acknowledge you, work with you on a fix, and credit you if you would like that.
Please give us a reasonable chance to fix an issue before disclosing it publicly, and please do not access, alter or retain data that is not yours while testing. We do not currently run a paid bug bounty.
Data deletion
Clients can request an export at any time during an engagement and a deletion after it. Platform accounts are deleted within 90 days of an engagement ending. Suppression and unsubscribe lists are deliberately kept, because forgetting that someone opted out would be the worse outcome. Full detail is in the Privacy Policy.
Questions
Security reviews, questionnaires and data processing agreements: support@brandmastersmedia.com.
Related: Privacy Policy · Sub-processors · Acceptable Use Policy · Terms of Use