Security & Compliance
Security in Marketing Central is a design constraint, not a checklist item. Authentication, authorization, data handling, and audit trails are all architectural decisions, not features added after the fact. The platform is designed to satisfy PCI scope minimization, PIPEDA compliance, WCAG 2.1 AA accessibility, and a 5-year data retention requirement from launch.
Data Security
Encryption in Transit
All data in transit uses TLS 1.2 or higher. HTTPS is enforced for all public-facing endpoints — no plaintext HTTP. All server-to-server communication with external integrations (Admin System, GP, Entra, payment processor, vendor APIs, carrier APIs) uses encrypted channels. Certificate management is handled via Azure.
Encryption at Rest
Azure SQL and Azure Blob Storage both support transparent encryption at rest by default within the Liberty Azure tenant. Sensitive fields (banking routing numbers, account numbers for ACH) are additionally encrypted at the application layer before storage — encrypted in memory before write, decrypted only in the server-side context where they're needed.
Secrets Management
All API keys, connection strings, and integration credentials are stored in Azure Key Vault. No secrets are stored in source code, environment files committed to version control, or application configuration that is not vault-backed. Secrets are accessed at runtime via managed identity — no static credentials in the deployment environment.
PCI Scope Minimization
Marketing Central never handles raw card data. The payment processor's hosted payment form or client-side tokenization handles card collection — card numbers never touch Liberty's or Bonfire's servers. This keeps Marketing Central out of PCI DSS scope for card data storage and transmission, significantly reducing compliance overhead.
5-Year Data Retention
Fund transaction records, claim records, audit logs, and order histories are retained for 5 years minimum. Retention is enforced at the database layer with configurable archival policies. Records flagged for legal or compliance hold are preserved beyond the standard retention period. Deletion of PII is handled separately per applicable privacy law requirements.
PII Masked in Logs
Personally identifiable information — franchisee banking details, account numbers, and contact data — is masked or scrubbed before any value is written to application logs, error traces, or monitoring telemetry. Diagnostic logging captures the context needed to investigate an issue without ever recording sensitive field values in clear text, so the observability pipeline never becomes a secondary store of unprotected PII.
Authentication & Authorization
Microsoft Entra ID (Corporate)
Corporate users — Marketing team, Admin, and Corporate View — authenticate via Microsoft Entra ID, Liberty's existing enterprise identity provider. SSO is already in place for Liberty's corporate applications; Marketing Central joins that single sign-on ecosystem. Multi-factor authentication is inherited from Liberty's existing Entra MFA policy — no separate MFA configuration required.
Entra External ID (Franchise + Vendor)
Franchisees and vendors authenticate via Entra External ID, the B2B/B2C extension of the Entra platform. This means franchisee and vendor identity management is integrated with Liberty's existing identity infrastructure — the same tenant, the same admin tools — while being isolated from the corporate identity pool.
User roles (Franchisee, Entity, Marketing, Admin, Corporate View, Vendor) are stored as Entra App Role assignments and delivered as claims in the JWT token on every authenticated request. The server-side middleware validates these claims on every API call. There is no separate role database to keep in sync with Entra — Entra is the role record. Adding or removing a role is an Entra action that takes effect immediately.
Token Validation on Every Request
JWT tokens are validated on every server-side API call — not just checked at session start. Expired tokens, revoked tokens, and tokens with tampered claims are rejected at the middleware layer before the request reaches application logic.
RBAC Enforced at Data Access Layer
Authorization checks happen at the data access layer, not just at the route level. A query for "orders" doesn't just check that the user is logged in — it filters to only the orders the user's scope permits. There is no "bypass the UI and hit the API" attack surface where a franchisee could retrieve another office's data by crafting a direct API call.
Compliance Standards
WCAG 2.1 AA
All franchise-facing UI screens meet WCAG 2.1 AA accessibility standards. This includes keyboard navigation, screen reader compatibility, sufficient color contrast, and focus management. Accessibility is tested as part of the QA process, not audited after launch.
PIPEDA (Canada)
Canadian franchisee data is handled in accordance with the Personal Information Protection and Electronic Documents Act. This includes consent management, data subject rights (access, correction), and breach notification requirements. Canadian data is identified at the record level for any jurisdiction-specific handling.
US PII Standards
Franchisee banking information (routing and account numbers) is treated as PII with application-layer encryption. Franchisee data is not shared with vendors beyond what is required to fulfill an order (name and shipping address). Marketing Central does not sell or share user data for commercial purposes.
PCI DSS Scope
Card data never touches Marketing Central's servers. Payment tokenization happens client-side via the payment processor's hosted tools. Marketing Central stores only a payment token and last-four digits — no card numbers, no CVV, no expiry dates. PCI compliance responsibility sits with the payment processor for card data.
Vulnerability Management
Automated dependency scanning (Dependabot or equivalent) runs continuously to flag known vulnerabilities in package dependencies. Security patches are treated as priority deployments. A formal penetration test is conducted before production launch, with findings remediated before go-live.
Disaster Recovery
Azure SQL geo-redundant backup with configurable RPO and RTO targets (specific values to be determined with Liberty during discovery). Azure Blob Storage is geo-redundant by default. Recovery procedures are documented and tested annually. Specific RPO/RTO commitments are subject to Liberty's operational requirements.
Audit & Monitoring
Application Insights
Azure Application Insights provides real-time performance monitoring, error tracking, and usage analytics. Every request is instrumented — latency, error rate, and dependency call performance are continuously monitored. Alerts are configured for error rate spikes, latency degradation, and dependency failures. The Application Insights dashboard is accessible to Liberty's technical team.
Security Event Logging
Authentication failures, authorization rejections, privilege escalation attempts, and unusual access patterns are logged as security events and routed to Azure Monitor. Configurable alert thresholds trigger notifications to Liberty's designated security contacts for events that warrant investigation.
Immutable Audit Log
The business audit log — covering fund transactions, claim lifecycle, emulation sessions, and admin actions — is written to an append-only table with no update or delete permissions at the application layer. Log records are timestamped by the database server (not the application clock) to prevent client-side timestamp manipulation. Audit logs are retained for 5 years minimum.
Penetration Testing
A formal penetration test is conducted by a qualified third party before production launch. The scope includes authentication flows, API authorization, injection vulnerabilities, and the emulation system. Findings are categorized by severity; critical and high findings are remediated before go-live. A follow-up test at 12 months post-launch is recommended.
Data Ownership & Exit Strategy
Liberty owns the platform and everything in it. Ownership is not a clause that activates at the end of an engagement — it is the architecture from the first commit. There is no scenario in which Liberty's data, source files, or code are held by a vendor or trapped in a proprietary format.
Full Data Export on Demand
At any time, Liberty can export the complete data set — all assets together with their metadata, and the full transaction history across funds, orders, and claims — in open, documented formats (CSV, JSON, and standard file types). Export is a supported platform capability, not a special-request favor that depends on Bonfire's cooperation.
Original Files Warehoused
Liberty's source files are retained intact — not just the rendered or derived output. Illustrator and PDF originals, uploaded receipts, and brand assets are stored in their original form in Liberty's Azure Blob Storage. If Liberty ever needs the editable source rather than a flattened export, the source is already there.
No Lock-In
All code and all data live in Liberty's own Azure tenant. There are no proprietary Bonfire data formats, no encrypted vendor-only stores, and no hosted black box. Anyone with the appropriate Azure access — Liberty's team or a future vendor — can read the database and the blob store directly using standard tooling.
Migration Support on Termination
If the engagement ever ends, Bonfire provides a structured export and active migration assistance so Liberty can move the platform and its data to another team or environment cleanly. There is no hostage risk and no leverage point — the exit path is defined up front so the decision to stay is always Liberty's, made on the merits.
From the first line of code to the last receipt uploaded, every asset, record, and source file belongs to Liberty and lives in Liberty's environment. Bonfire builds and operates the platform during the engagement, but ownership never transfers because it was never Bonfire's to hold. The exit strategy is simple precisely because there is nothing to claw back.
Single Sign-On & Identity Federation
Marketing Central authenticates corporate users through Microsoft Entra ID and franchise and vendor users through Entra External ID. Entra federates with Liberty's existing Active Directory and supports SAML 2.0 — as well as OIDC — for single sign-on. The practical result is that users reach Marketing Central directly from the Liberty Resource Center without a separate login: they are already authenticated by Liberty's identity provider, and Marketing Central honors that session.
Roles live in Entra app roles, and data scope always derives from the Admin System. Because of this split, Marketing Central does not depend on the legacy "User Manager" application to know who a user is or what they can do. That removes a brittle dependency on an aging internal system while still fully honoring the RFP's SAML 2.0 single sign-on requirement — SSO comes from Entra's federation with Active Directory, not from a custom user-management layer Liberty would have to keep alive.
Localization & Language
The franchise-facing experience is localized to each market. The US market is served in English and Spanish; the Canadian market is served in English and French — French support reflects the expectations of a PIPEDA-governed, officially bilingual market. Localization is not limited to a translated label here and there: it covers UI labels, legal disclaimers, and currency and number formatting.
Language and format selection is driven by the same per-country configuration that powers the US/CAN toggle, so a single configuration substrate governs which market a user is in, which currency and formats apply, and which language strings are served — keeping the two markets consistent and independently maintainable.