Our principle
Security starts with collecting less sensitive information when a task can be completed without it. We separate editorial tools and low-sensitivity routing from workflows that genuinely require identity or financial information.
Technical and organizational measures
Depending on the published architecture, controls may include encryption in transit, protected storage, access controls, least-privilege permissions, logging and monitoring, vulnerability management, secure development practices, backups, secrets management and documented incident-response procedures. The public page should describe controls at a level that is accurate without exposing information that would weaken security.
Service providers
Hosting, analytics, communications, security and lead-routing vendors can create additional risk. We evaluate service providers according to the sensitivity of the data and the role they perform and require appropriate contractual and technical safeguards where applicable.
Incident response
A security program should include a process to identify, contain, investigate and remediate suspected incidents, preserve evidence and provide legally required notifications. The incident plan must exist operationally; it should not be claimed simply because the website publishes a security page.
What users can do
Use the official site domain, verify unexpected emails or texts before responding, avoid sending sensitive information through general support channels, use secure devices and networks, and report suspicious activity or impersonation promptly.
No absolute guarantee
No website, system or transmission method can guarantee perfect security. We avoid claims such as “100% secure” and instead describe the measures and response processes that are actually in place.
