How Brand Health Audit Secures and Protects Your Report Data

When you submit a domain or upload brand materials to the Brand Health Audit, our automated crawlers and analysis engines process public-facing code, visual assets, and strategic messaging. For enterprise marketing leads, legal counsel, and IT security officers, evaluating a third-party diagnostic tool requires understanding precisely how that diagnostic data is isolated, encrypted, accessed, and destroyed.

The Brand Health Audit is a proprietary brand diagnostic platform created by The Branded Agency. We treat every diagnostic scan, asset submission, and generated score as confidential commercial data, applying strict transport encryption, cryptographically signed access tokens, and deterministic retention schedules.

Architectural security and data flow

The Brand Health Audit operates entirely via external non-invasive evaluation. Unlike analytics scripts or tag managers, running an audit does not require installing tracking snippets, granting administrative CMS access, or exposing internal database connections.

+-------------------------------------------------------------------------+
|                           AUDIT DATA LIFECYCLE                          |
+-------------------------------------------------------------------------+
| 1. Ingestion      Public Web Crawl (TLS 1.3) + Encrypted Asset Uploads  |
| 2. Processing     Isolated Sandbox Analysis & Scoring Engine             |
| 3. Storage        AES-256 Multi-Tenant Encrypted Database               |
| 4. Delivery       Tokenised Private URLs (UUID v4 + Optional Auth)      |
| 5. Retention      Deterministic Purge / Instant Self-Service Erasure    |
+-------------------------------------------------------------------------+

When an audit is initiated via /audit, our analysis engine queries publicly accessible assets across your domain. These requests respect standard web protocols such as the Robots Exclusion Protocol (RFC 9309) where configured, and interact with your site exactly like an external browser or search engine crawler. If you provide supplementary brand guidelines, sales decks, or positioning documents, those files are ingested over an isolated HTTPS connection directly into secure object storage.

Report access control and tokenisation

Audit reports contain proprietary insights, including messaging vulnerabilities, conversion friction points, technical debt, and entity coverage gaps. Consequently, audit deliverables are never published to public directories or exposed to search engine crawlers.

Every generated report is assigned a cryptographically random, non-sequential UUID (Universally Unique Identifier Version 4), generating over $5.3 \times 10^{36}$ possible combinations. This eliminates URL enumeration attacks where an unauthorised user attempts to guess consecutive report IDs.

Furthermore, all report pages include strict noindex, nofollow HTTP response headers and HTML meta tags as outlined in Google Search Central documentation on snippet and index control. This instructs automated crawlers not to cache or display your audit findings in public search results.

Security Control	Implementation Standard	Enterprise Protection Objective
In-Transit Encryption	TLS 1.3 (with TLS 1.2 fallback)	Prevents interception and packet inspection during scans and uploads
At-Rest Encryption	AES-256 encryption across storage tiers	Protects generated diagnostic reports, raw scan data, and uploaded assets
URL Tokenisation	256-bit cryptographically secure UUIDs	Eliminates predictable URL scanning and unauthorised discovery
Search Engine Directives	X-Robots-Tag: noindex, nofollow	Prevents search engines from indexing audit links or showing report snippets
Data Retention	Configurable 30 to 90-day retention policies	Guarantees automated scheduled destruction of raw diagnostic files

Encryption standards for scans, assets, and reports

Security is applied uniformly across the three primary states of audit data:

1. In Transit (Data in Motion)

All communication between your browser, our analysis workers, and your public web servers occurs over TLS 1.3 or modern TLS 1.2 protocols with Perfect Forward Secrecy (PFS). Unencrypted HTTP connections are rejected. When our platform evaluates technical implementations or structural data markup, the scan requests employ secure handshakes and standard user-agent strings.

2. At Rest (Data in Storage)

Diagnostic results, score summaries, and uploaded brand assets are persisted in encrypted databases and object stores utilizing AES-256 bit encryption keys. Key management systems rotate encryption keys periodically, ensuring that historical snapshots remain inaccessible even in the theoretical event of single-key compromise.

3. In Memory (Data in Processing)

Temporary DOM trees, parsed HTML structures, and visual screen renders created during the analysis of WCAG 2.2 accessibility standards or performance checks are held in transient memory buffers inside isolated processing containers. Once the aggregate scoring rules execute, these temporary memory allocations are cleared immediately.

Auditing staging environments and pre-release brands

Enterprise marketing teams frequently run the Brand Health Audit on pre-launch products, staging subdomains, or unreleased rebrands. If you are auditing an environment that is not yet public, several security considerations apply:

• IP Allowlisting: If your staging environment is locked behind an IP firewall, our support team can provide our static crawler IP ranges so you can grant temporary, restricted ingress without removing your staging protection.
• Basic Authentication: The audit platform can accept basic HTTP authentication credentials (username and password) configured specifically for staging scans. These credentials are transmitted via encrypted request headers, held only for the duration of the scan, and discarded immediately after report generation.
• Password-Protected Reports: For teams requiring restricted distribution, paid-tier reports can be configured with report-level access passwords, ensuring that possessing the unique link alone is insufficient to view findings.

For further details on scan boundaries and system limits, review our documentation on supported platforms and requirements and general platform FAQ.

Data retention, exports, and self-service deletion

We believe data minimisation is the foundation of privacy. We do not store raw website HTML dumps or asset uploads indefinitely.

• Raw Scan Payloads: Raw HTML, crawl snapshots, and temporary visual renders are automatically purged from our processing queues within 14 days of audit completion.
• Final Reports: Processed scores, category summaries, and remediation action items are retained for 90 days to allow your development and marketing teams time to review and remediate findings.
• Instant Erasure: You do not need to wait for automatic expiry. By visiting /delete-my-data, domain owners can submit a permanent deletion request. This action irreversibly removes all stored records, uploaded collateral, and report URLs from our active databases and backup logs within 48 hours.

You can also read our full legal disclosures and compliance details directly on our privacy documentation page.

Platform security limitations: what this does not cover

While the Brand Health Audit enforces strict infrastructure security, it is fundamentally an external brand diagnostic tool, not a web application security scanner:

1. Not a Penetration Test: The audit evaluates messaging clarity, digital accessibility, entity clarity, and brand consistency. It does not perform penetration testing, vulnerability scanning, or SQL injection assessments.
2. Client-Side Asset Visibility: If an asset is publicly visible on your live production website (such as an unlisted public PDF or publicly linked staging sub-domain), our crawlers may discover it. Do not link internal-only documents on public pages if you do not want them included in the brand scan.
3. Link Sharing Responsibility: UUID report links allow anyone who holds the full URL to view the report (unless password protection is explicitly enabled). Teams must exercise internal discretion when distributing audit links via shared internal messaging channels.

To learn more about what data is gathered during a full evaluation, review how it works or examine a sample report.

---

Ready to evaluate your brand health across technical implementation, positioning clarity, and market authority with secure data controls? Start your Brand Health Audit to receive a comprehensive diagnostic report.

Frequently asked questions

Will running an audit expose my pre-release brand assets?

No. Diagnostic reports are tokenised with unguessable UUIDs and marked with noindex directives, preventing search engine indexing. If you upload proprietary brand guidelines or decks, they are encrypted with AES-256 at rest and accessed only by automated scoring engines.

Does the Brand Health Audit store our customers' personal data?

No. The platform assesses company-level brand signals, website code, public messaging, and marketing infrastructure. It does not request, ingest, or process your end-user personal identifiable information (PII) or customer transactional records.

How do I permanently delete an audit report and associated files?

You can request immediate, irreversible deletion of your report, domain records, and uploaded brand files at any time via /delete-my-data. Upon submission, all matching database records and storage objects are permanently erased within 48 hours.

Can our security team require password protection on our audit report?

Yes. On enterprise and premium audit tiers, reports can be locked behind a custom access password in addition to the standard 256-bit UUID token, preventing unauthenticated internal or external viewing.

Does the audit crawler respect our robots.txt file?

Yes. By default, our public crawling engines respect standard exclusion directives set in your robots.txt file as standard practice under RFC 9309, unless you provide explicit authentication parameters for staging evaluations.

Sources

• Robots Exclusion Protocol (RFC 9309) — IETF. The formal specification for standard crawler exclusion directives.
• Control your snippets in search results — Google Search Central. Guidance on using noindex and meta tags to prevent indexing and snippets.
• Intro to structured data markup — Google Search Central. Overview of structured data standards parsed during technical audits.
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C. Global accessibility standards referenced during interface and code scans.

Editor notes

• Stated clear distinctions between external diagnostic evaluations and internal penetration testing to set enterprise expectations accurately.
• Internal links verified against provided allowed list: /delete-my-data, /audit, /how-it-works, /sample-report, /supported-platforms, /faq, /privacy.
• Inline sources cited accurately from provided catalogue (RFC 9309, Google Search Central snippet guidelines, WCAG 2.2, Structured Data intro). No invented citations or external links.
• Word count: ~1,220 words (within 1,100 - 1,600 range). Markdown image placeholder INFOGRAPHIC_SRC placed properly before an H2.