Trust Center

Branded Mayhem Collective

Branded Mayhem Collective is the Richardson, Texas holding company behind 8gnc, the agency, and br8n, the practice that installs AI-delivery capability inside client organizations.

We build and operate digital systems for other people’s businesses, so how we handle access, secrets and data is a fair thing to ask about before the first engagement.

What follows is what we actually run, verified rather than asserted — alongside a register of what we have not closed yet. The gaps are published on purpose. A wall of green checks with nothing behind it is easy to write and worth nothing to a reviewer.

[email protected]Sortlist profile ↗

Compliance

BMC holds no certification in any framework below. Our 7 August 2026 SOC 2 self-assessment scored 73.7% readiness: 20 controls met, 16 partial and 2 missing across 38 controls. The audit has not been performed yet. The governance layer was adopted and signed on 6 and 7 August 2026; the remaining distance is operating evidence, not paperwork. Controls are being brought to evidence one at a time, after which a single unified audit will be performed by an independent firm; Schellman and A-LIGN are the two we are weighing. Until that firm issues a report, everything here describes our own work, not a third party’s attestation.

ISO/IEC 27001Information security managementReadiness

ISO/IEC 27017Cloud services securityReadiness

ISO/IEC 27018Personal data in the cloudReadiness

SOC 2Security, availability, confidentiality73.7% readiness

ISO/IEC 42001AI management systemsReadiness

NIST AI RMFAI risk managementReadiness

GDPREU data protectionReadiness

CCPACalifornia privacyReadiness

Resources

Data Processing AgreementRequired before client data reaches any system we operate.On request

Sub-processor and DPA registerEvery third party that touches client or operational data, with the status of each agreement.On request

AI tooling and client data policyWhich class of data may reach which AI tooling, and the DPA-backed route required before BMC operates client-data AI.On request

Privacy rights procedure and request channelAccess, deletion, correction and opt-out requests are accepted at [email protected] and tracked through a documented procedure.Available

What we have not closed, with the plan for each. Published rather than gated.Published

Certification reportsNo independent firm has examined us, so no report exists to send. This page will say so until one does.Does not exist yet

Controls

Verified 7 August 2026

Full-disk encryption enforced on workstations
Host firewall enabled on workstations
TLS on all public surfaces, with HSTS and a hardened response-header set
Persistent application, database and agent-runtime state is confined to separate LUKS2-encrypted volumes; unencrypted server root disks hold replaceable operating-system and configuration state only
Production database and application listeners bind only to loopback or authenticated private paths, never directly to the public internet
Both production Linux hosts enforce named key-only administration, disabled root and password login, default-deny host firewalls, intrusion blocking, audit logging, mandatory access controls and unattended security updates

Multi-factor authentication required across the source-control organization
Secrets centralized in a managed secret store; no plaintext secrets in source
Security-awareness evidence includes 70 continuing-education credits across four dated credentials
AI system register, risk assessment and impact assessments adopted as maintained records for BMC-operated AI use

Pull requests required across all active repositories, with deletion and non-fast-forward updates blocked
Application error monitoring with alerting
Agent execution and the production data plane are isolated on separate hosts with disjoint runtime authority

Sub-processor inventory maintained, each vendor agreement verified against its actual terms
Privacy rights requests accepted through a monitored channel with a documented handling procedure
Global Privacy Control is honored on this site for advertising-consent signals
Data residency documented per system and disclosed in the sub-processor table

Production-data and agent-runtime snapshots are encrypted client-side before off-site storage, with separate primary and break-glass repository credentials
Current application, volume-state and encryption-header restores passed integrity checks
Source control mirrored one-way to separate off-site storage, daily
Uptime monitoring with alerting on public surfaces

Open gaps

Published deliberately. Every entry names the gap, where it actually stands, and what happens next — no gap is listed without a plan.

No certification, and the audit has not been performed

Where it stands

BMC holds no ISO, SOC 2, or equivalent certification. Readiness work is underway and controls are being brought to evidence against the frameworks above, but no independent firm has examined us and no report exists.

What happens next

Controls are brought to evidence first, then a single unified audit by an independent firm covering the frameworks above rather than one engagement per standard. Certification marks and reports appear on this page when that firm issues them, and not a day earlier.

Encrypted backup and restore controls have point-in-time, not recurring, evidence

Where it stands

The permanent data and agent hosts each have encrypted off-site repositories with independent primary and break-glass credentials. Application data, volume state and encryption-header restores passed integrity checks on 3 August 2026, and both repository credentials were tested independently. Those are current point-in-time results; they are not yet retained operating evidence across an observation window.

What happens next

Assign exactly one scheduler to each backup path, document retention, alert on failed or stale snapshots and retain quarterly restore results. Until that history exists, we describe the repositories as encrypted and restore-tested, not as a recurring Type II control.

Governance is newly adopted, so operating history is thin

Where it stands

The core policy set, risk register, AI management charter and privacy determinations were reviewed, signed and adopted by the Owner on 6 and 7 August 2026, with versioned adoption records on file. What does not exist yet is history: recurring reviews, measured indicators and cadence evidence all start from this month.

What happens next

Run the adopted cadences and keep the dated records: first management review, quarterly access reviews, indicator measurements. Adoption matures into operating effectiveness only through that retained history.

The incident-response plan is adopted but not yet exercised

Where it stands

The incident-response policy was adopted on 6 August 2026 with monitoring and escalation paths in place. No tabletop exercise has yet produced evidence that the plan executes under pressure.

What happens next

Run a tabletop against a realistic scenario, record findings, owners and remediation dates, and extend the plan to AI-specific incident classes.

Vulnerability and centralized security monitoring remain incomplete

Where it stands

The production Linux hosts now have audit logging, intrusion blocking, mandatory access controls, automatic security updates, persistent journals and runtime health monitoring. BMC still does not operate a complete vulnerability-scanning program, EDR or SIEM, scheduled centralized log reviews, managed-device enforcement, or application allowlisting. Repository rules also do not yet require an approving review or passing status check before merge.

What happens next

Sequence the remaining baseline as vulnerability scanning and required repository checks first, then managed-device, endpoint-detection and centralized review controls with retained operating evidence.

The access review is not fully attested

Where it stands

Access-control procedures and inventories exist, but the current review is not complete across every system and does not yet carry the Owner attestation needed for audit evidence.

What happens next

Complete the system-by-system access review, remove or justify exceptions, obtain Owner sign-off and repeat it on a fixed cadence.

One content platform routes to AI providers we do not control

Where it stands

Our content management platform names OpenAI, Google Cloud and Anthropic as its own sub-processors, and its agreement does not limit hosting to the European Union. Content placed in that platform can therefore reach AI providers through the vendor’s supply chain rather than ours. Our internal policy governs what we put into AI tools; it does not reach what a vendor does downstream, and we would rather say so than let the sub-processor list imply a tighter boundary than exists.

What happens next

Establish per-client whether that platform is the right home for their content, and disclose this chain in the engagement rather than at the point a questionnaire finds it. Where a client needs AI processing kept out of the content layer, the platform choice changes.

One content platform operates outside DPA coverage, under a documented use restriction

Where it stands

Sanity stores structured site content for one property and offers no self-serve data-processing agreement. Rather than leave that ambiguous, we audited the full dataset on 7 August 2026: no end-user records, lead records, form submissions, or account records exist there — the project is restricted to public-bound editorial and marketing content, whose only identified personal data is the operator’s own author byline. On that basis we adopted a signed current-use limitation determination: Sanity is prohibited from holding client personal data, end-user personal data, form data, or personnel data, and the audit re-runs on any schema change or annually. Sanity’s own attestation is SOC 2 Type 2; the ISO 27001 certification on its security page belongs to its infrastructure provider, and we will not repeat that claim on its behalf.

What happens next

Operate under the determination’s use restriction. Client work requiring personal data in a content layer uses a DPA-covered platform instead. The determination reopens if the schema changes, an engagement subject to GDPR touches this content, or Sanity publishes a DPA we can adopt.

No DPA-backed BMC-operated client AI plane or active technical routing control

Where it stands

A fail-closed routing guard has been implemented and unit-tested in source, but it is not yet activated in BMC’s operating dispatcher. No BMC-operated client AI route is active today. Client data therefore has no permitted fallback to a personal subscription; client work remains in the client’s own licensed environment until the operating control and commercial evidence are complete.

What happens next

Activate the guard and a client route only after the commercial agreement, executed DPA, isolated Doppler project and client-specific processing decision are evidenced. Client-ZDR use remains inactive until a client requirement and compatible provider terms are in place.

No Content-Security-Policy

Where it stands

Public surfaces carry HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy, but no CSP.

What happens next

Staged: report-only CSP first, tightened on collected violation evidence, then enforced. A rushed policy full of unsafe-inline would be worse than none.

HSTS preload staged, not complete

Where it stands

HSTS is live on all three domains with a one-year max-age and includeSubDomains. The preload token now serves on this domain; the other two carry it in configuration but have not shipped the deploy that puts it on the wire. No domain has been submitted to the browser preload list, and submission is not accepted until a domain is already serving the token.

What happens next

Submit this domain after a 30-day observation window, then the other two once their deploys land. Preload is difficult to reverse, which is the whole reason for the wait.