Trust Center
Security and Data Protection
Every Infixs product runs on infrastructure we harden, monitor and review continuously. This page explains, in plain language, the controls we use to keep intruders out and to keep your data and your customers’ data private.
Built on infrastructure and tooling trusted by millions of businesses worldwide.
Defense in depth, not a single wall
Any single control can fail. That is why an attacker trying to reach your data has to defeat five independent layers, each one with its own rules, its own logs and its own failure mode.
How we keep intrusions out
Ten control areas, applied to our websites, our APIs, our license servers and the plugins we ship to you.
Edge protection and DDoS mitigation
All traffic to Infixs services passes through Cloudflare before it can reach an origin server.
- Managed WAF rules covering the OWASP Top 10
- Volumetric and application-layer DDoS mitigation
- Bot management and challenges for suspicious clients
- Rate limiting on login, checkout and API endpoints
- Origin IP addresses are never exposed publicly
- TLS 1.3 termination with modern cipher suites only
Hardened cloud infrastructure
Our workloads run on Google Cloud Platform, in data centres certified to ISO/IEC 27001, ISO 27017, ISO 27018 and SOC 1/2/3.
- Private VPC networking; databases are never exposed to the internet
- Firewall rules default to deny, only required ports are opened
- Managed, automatically patched operating system images
- Redundant zones so a hardware failure does not become an outage
- Infrastructure changes are versioned and reviewed
Encryption everywhere
Data is encrypted while it travels and while it sits still. There is no unencrypted path.
- HTTPS enforced with HSTS, plain HTTP always redirects
- Certificates issued and renewed automatically
- AES-256 encryption at rest for databases, storage and backups
- Passwords stored as salted one-way hashes, never in plain text
- API keys and credentials kept in a managed secret store, never in code
Identity and access management
Access is granted by exception, not by default, and every privileged action leaves a trail.
- Two-factor authentication on administrative and cloud accounts
- Least-privilege IAM roles, no shared root logins
- Key-based SSH only, password authentication disabled
- Access reviewed periodically and revoked as soon as it is no longer needed
- Administrative actions written to an audit log
Secure development lifecycle
Security is applied while the code is written, not bolted on after release.
- Code review before anything reaches production
- Prepared statements and strict input validation against SQL injection
- Output escaping and nonce/CSRF verification on every form and AJAX route
- Capability checks on every privileged action, following WordPress standards
- Dependency and vulnerability scanning across our libraries
- Separate development, staging and production environments
Continuous monitoring and logging
We assume something will eventually look wrong, so we make sure we see it early.
- Centralised application, access and error logs
- Uptime and performance checks with automatic alerting
- Anomaly detection on traffic spikes and failed-login patterns
- File integrity and malware scanning on WordPress installations
- Alerts routed to an engineer, not to an inbox nobody reads
Backups and disaster recovery
A backup only exists once it has been restored successfully.
- Automated, encrypted backups with redundant off-site copies
- Point-in-time restore for databases
- Restore procedures tested periodically
- Documented recovery runbooks for each critical service
Payments and financial data
Infixs never sees, handles or stores your card number.
- Payments processed exclusively by PCI DSS certified providers
- Card data captured by the provider and tokenised, never touching our servers
- Checkout served over TLS with anti-fraud analysis at the gateway
- Refunds and disputes handled through the provider’s audited flow
Update and supply-chain integrity
The update channel is part of the attack surface, so we treat it like one.
- Plugin updates delivered over authenticated HTTPS channels
- License validation over encrypted connections only
- No obfuscated or remotely executed third-party code in our products
- Minimal and documented telemetry, limited to technical data
Vulnerability management
Known problems get fixed before new features get built.
- Continuous monitoring of CVEs affecting our stack
- Security patches prioritised above feature work
- Periodic internal security review of our own products
- A coordinated disclosure channel open to anyone
What happens to a request before it touches your data
Five checkpoints, in order, on every single request.
The request leaves the browser over an encrypted TLS 1.3 connection.
WAF rules, DDoS filtering, bot checks and rate limits run before anything reaches us.
Traffic enters a private network with a deny-by-default firewall.
Authentication, capability checks and strict input validation are applied.
Encrypted at rest, reachable only from the application, every access logged.
Control coverage by layer
The same view in a single table, so you can see exactly what protects what.
| Layer | Primary controls | Technology |
|---|---|---|
| Edge | WAF, DDoS mitigation, bot management, rate limiting | Cloudflare |
| Network | Private VPC, deny-by-default firewall, no public database | Google Cloud |
| Platform | Patched images, least-privilege IAM, key-based SSH | Google Cloud |
| Application | Input validation, CSRF nonces, output escaping, capability checks | Infixs coding standards |
| Data | AES-256 at rest, TLS 1.3 in transit, hashed passwords | Google Cloud, Let’s Encrypt |
| Operations | Centralised logs, alerting, encrypted backups, restore tests | Google Cloud and internal tooling |
How we treat your data and your customers’ data
We collect the minimum needed to make the product work and to support you. Nothing else, and never for resale.
What we do
- Collect only the data a feature actually needs to work, such as shipping calculations, license validation and support
- Store data on Google Cloud infrastructure with encryption at rest and in transit
- Keep data only for as long as it is needed or legally required, then delete it
- Sign confidentiality and data-processing terms with every provider we use
- Answer LGPD and GDPR requests: access, correction, deletion and portability
- Notify you if an incident ever affects data under our responsibility
What we never do
- Sell, rent or trade personal data
- Use your customers’ data to train models or to profile them commercially
- Store payment card numbers on our servers
- Share data with third parties without a legal basis
- Intentionally collect sensitive personal data
- Access your site’s data without your request or an explicit support authorisation
Who processes data with us
We keep the list of subprocessors short and we choose them for their security posture, not their price.
| Provider | Purpose | Safeguards |
|---|---|---|
| Google Cloud Platform | Hosting, databases, object storage and backups | ISO/IEC 27001, 27017, 27018, SOC 1/2/3, encryption at rest and in transit |
| Cloudflare | DNS, CDN, WAF and DDoS mitigation | ISO/IEC 27001, SOC 2 Type II, TLS 1.3, global edge filtering |
| Payment providers | Payment processing and fraud analysis | PCI DSS certified, card data tokenised and never stored by Infixs |
| Email and support tools | Transactional notifications and customer support | TLS in transit, access restricted to the support team, retention limits |
Retention and deletion are governed by our Privacy Policy: data linked to your account is kept while the account remains active, and you can request deletion at any time by writing to [email protected]. LGPD/GDPR rights requests — access, correction, portability — follow the same policy.
Access control policy
Who can access data under our responsibility, and under which rules. The governing principle is least privilege: access is granted by exception, reviewed, and revoked when no longer needed.
Who has access
- Only team members who need the data to do their job — support and operations — on a need-to-know basis
- Individual, named accounts only; shared credentials are not used
- Two-factor authentication on administrative and cloud accounts
- Access to a client’s site or store happens only with the client’s request or an explicit support authorisation
How access is governed
- Least privilege: every account carries the minimum role its work requires
- Access is granted by exception, never by default
- Access is reviewed periodically and revoked as soon as it is no longer needed — on role change or departure, immediately
- Administrative and privileged actions are written to an audit log
Incident response policy
A security incident is any event that compromises — or credibly threatens — the confidentiality, integrity or availability of our services or of data under our responsibility. When one happens, this is the sequence we follow.
If an incident affects data under our responsibility, you hear it from us: notifying affected customers — and, where the LGPD requires it, the ANPD within the legal deadline — is part of the procedure, not a courtesy. We would rather tell you about an incident than have you discover it.
Security is shared, and here is your part
Our controls protect our infrastructure and our code. These are the ones that protect your store.
Turn on two-factor authentication
Enable 2FA for every WordPress administrator. It stops the vast majority of credential-stuffing attacks on its own.
Keep everything updated
WordPress core, themes and plugins. Most compromised stores were running a version with a publicly known fix available.
One account per person
Give each person their own login with the lowest role that lets them do their job, and remove access when they leave.
Strong, unique passwords
Use a password manager. A password reused from another service is the same as no password at all.
Keep your own backups
Our backups protect our infrastructure. Keep independent backups of your store and test a restore at least once.
HTTPS across the whole site
Not just checkout. Mixed content leaks session data and breaks the guarantees TLS is there to provide.
Found a vulnerability? Tell us.
We welcome reports from security researchers and from customers. Send a clear description and reproduction steps to [email protected]. We will acknowledge your report, keep you updated on the fix, and we will not pursue legal action against good-faith research that respects user privacy and avoids service disruption or data destruction.
Related: Privacy Policy · Terms of Use
Last updated: August 2026