COMPLIANCE · WHAT IS NEEDED
What is needed for compliance
Gramm-Leach-Bliley requirements for a security-awareness service provider. Updated October 12, 2026.
At a glance
- Regulator
- FTC (banks’ primary federal regulators separately)
- Rules
- Privacy Rule 16 CFR Part 313; Safeguards Rule 16 CFR Part 314
- Our role
- Service provider under the Safeguards Rule
- Primary obligations
- Maintain safeguards; contractually assure customers; provide due-diligence evidence
- Not our role
- Issuing consumer privacy notices or managing opt-outs (the institution’s obligation)
How Gramm-Leach-Bliley applies
GLBA (the Gramm-Leach-Bliley Act, 15 U.S.C. § 6801 et seq.) and the FTC rules that implement it regulate "financial institutions" — a term the law defines broadly. Banks, credit unions, mortgage lenders, investment advisers, insurers, and financial-planning or tax-prep firms are the typical GLBA institutions. Those institutions must give their consumers privacy notices and opt-out rights (the Privacy Rule, 16 CFR Part 313) and must maintain a written information-security program (the Safeguards Rule, 16 CFR Part 314).
This platform is a service provider to those institutions. Under the Safeguards Rule a financial institution is still responsible for the protection of the information it shares with a service provider, and the rule requires the institution to obtain contractual assurances that the provider maintains safeguards. "What compliance requires" for a service like this one is therefore a combination of (a) protections this platform builds into the product and operates, and (b) the agreement, assurance, and evidence a customer's compliance team needs to contract for and receive.
Controls this platform provides
Role-based access (SUPER_ADMIN, organization admin, campaign/training manager, report viewer), strict per-organization data isolation that is enforced and regression-tested in every list/read/write path, mandatory two-factor authentication on sign-in with 30-day remembered devices and single-use recovery codes, and a 2-hour idle session timeout.
Encryption throughout: HTTPS for the application, TLS (STARTTLS or TLS) enforced for all outbound SMTP (the platform refuses to send over an unencrypted connection), and AES-256-GCM encryption of stored secrets — SMTP credentials, DKIM signing keys, darkweb-monitoring API keys, MFA secrets — via the platform's SecretBox envelope. Passwords are bcrypt-hashed with a per-account rate-limited, lockable login.
Audit logging of administrative, billing, training, and phishing-domain actions with actor, organization, action, and timestamp; CSRF protection on every state-changing request; and content-policy validation so campaign templates cannot contain external links, data: URIs, or JavaScript.
Data minimization: simulated-phishing pages record click/engagement behavior and training outcomes for the organization's own program — the platform does not collect credentials or MFA codes typed into mock pages, and it holds no payment-card data (PayPal handles payments).
Controls the platform operates
A written information-security program matched to the platform's size and complexity, with a named responsible lead, a documented risk assessment, and incident-response and vulnerability-management procedures.
Independent evidence of the program: an audited SOC 2 Type II report and a third-party penetration test, available to customers under a mutual NDA, plus a business-continuity/backup posture with encrypted backups.
Restricted staff access to production (least privilege, MFA for all staff, and structured change control) and evaluation of the hosting/datacenter provider's physical and environmental controls.
What the customer's compliance team should receive
A data-processing addendum (DPA) with safeguards wording: this platform processes information solely to provide the service to the customer, does not sell it, does not use it for its own marketing, and applies the control set described above.
A sub-processor list (hosting provider, SMTP relays, debug/error tools, PayPal for billing, and any darkweb-monitoring data providers) with the commitment to notify before adding a sub-processor, and breach-notification commitments so the customer can meet its own notification obligations in the event of unauthorized access.
Storage-location and data-retention terms: where data is hosted, how long it is kept (including the ability to delete or export program data when the contract ends), and the process for returning or erasing information.
Supporting documentation for vendor due diligence: the SOC 2 report, penetration-test summary, the security program overview, and completed security questionnaires (SIG or the institution's own) as requested.
What institutions should double-check for themselves
Whether the institution's own GLBA program treats this service as a service provider under the Safeguards Rule, whether the workforce information this platform processes is "nonpublic personal information" for that institution's purposes, and how consumer opt-out elections interact with the data shared with the platform.
Whether any additional regulatory framework applies to the institution and reaches the platform — for example HIPAA for a health-plan client, state data-protection statutes (such as the Massachusetts standards, 201 CMR 17) that reach any organization holding personal information of residents, and all U.S. state breach-notification laws.
Confirmation of the platform's current sending identity and mail protection controls, published at https://fairlyoffensive.com/docs on the whitelisting guide, so the institution's own email-security controls and allowlists stay consistent.
Requesting supporting evidence
Compliance and vendor-management teams can request a mutual NDA, then receive the current SOC 2 Type II report, third-party penetration-test summary, the written security-program overview, and a completed SIG or the institution's own security questionnaire by contacting support@fairlyoffensive.com.