Our approach to security
We protect every site, including staging sites, behind CloudFlare’s Enterprise WAF, with managed and customer rulesets as well as per-IP rate limiting actively blocking attacks every day. All sites run in isolated containers. Backups run as ZFS snapshots and replicate off-site at a completely different datacenter owned by a different infrastructure provider for redundancy. SSH and SFTP route through a dedicated gateway that scopes every session to a single customer. Vulnerability scanning runs daily and on-demand against every site we host.
We’re more interested in what actually keeps a site safe than in what’s on a procurement checklist. Where those two diverge, and they often do, we’ll tell you which one we’re choosing and why, in the section it applies to. If you need formal compliance documentation or audit support, see Compliance & audits at the end of this page.
Infrastructure & Network Security
All traffic is filtered through CloudFlare’s Enterprise WAF. That means every request to a site you host with use goes through several layers of protection before reaching our servers:
- Layer 3, 4, and 7 DDoS protection with no bandwidth cap
- Multiple Cloudflare-managed rule sets that cover the OWASP TOP 10, broad credential-exposure, web-shell and config-leak patterns
- We implement a robust set of custom rules designed to cover common attack patterns on WordPress sites
- CloudFlare Super Bot Fight Mode tackles emerging bot threats
- We maintain a custom set of challenge rules that present millions of automated bot requests per week with JavaScript or manage challenges before reaching your site
- Per-IP rate limiting on the WOrdPress login and XML-RPC endpoints which blocks hundreds of thousands of brute-force attempts per day on customer sites
- HTTP/2, HTTP/3, TLS 1.3 supported. Cloudflare-to-origin connections also use TLS
Since we only accept incoming connections via CloudFlare and block all other access, our origin IPs are not published and if a request didn’t go through Cloudflare, it doesn’t reach your site.
Data centers in Canada and the United States:
Customers choose their primary region for each application we host. This ensures that your site is served from a datacenter in your preferred region.
Sites are isolated at the container level:
Each customer site runs in its own Docker-based environment with its own database, process isolation, and resource limits . A compromised plugin on one site has no path to another customer’s data, files, or credentials.
OS and stack are kept current:
Server-level OS patches are run daily and PHP/MariaDB/Nginx updates are applied on a quarterly cadence. Critical patches go out of band when the threat warrants it.
Bruteforce and XML-RPC protection are on by default:
WordPress login attempts and XML-RPC requests are rate-limited at the edge before they reach your site. This not only enhances security, but also helps performance by ensuring your server resources aren’t being used to serve these requests.
Protection for common user error:
We noticed that customers (or poorly coded plugins) often leak their data by mistake by publishing sensitive information like .swp, .sql, .git/, editor backup files, etc. in public directories. While it’s impossible to fully prevent bad security practices from users and 3rd party plugins, we block common patterns like these from public access at the web-server level.
Vulnerability scanning:
We run multiple scanners on customer environments:
- Malware detection across PHP and JavaScrip files on sites
- Vulnerability database checks for known vulnerabilities of installed WordPress plugins, themes, and WordPress core
Scans run daily, plus on-demand from the dashboard or when our team needs to investigate a specific site. Scan results are displayed prominently in the dashboard for your site so you can take appropriate action.
Application & Access Security
SFTP and SSH require public keys:
Many hosts have insecure SFTP connections with passwords they often show or email in plaintext, that are often shared between users. We disable password authentication and keyboard-interactive authentication at the SSH daemon layer. Public-key authentication is the only way in, ensuring customers can’t use leaked credentials and sharing of credentials is less likely. We only ever see the public key. Your private key never touches our servers.
SSH access goes through a dedicated gateway, not direct to the origin:
Customer SSH and SFTP connections terminate at a TangibleXP SSH gateway that tunnels the connection to the right application server. Customer sessions are scoped to a single application. They do not get root, shell access on shared infrastructure, or any path to other customers’ files, databases, or processes
Customer credentials are never stored in plaintext:
WordPress admin passwords are hashed by WordPress itself, as designed. Dashboard passwords are also hashed. We never see, store, or transmit a plaintext password for any customer account.
Infrastructure as code:
Server provisioning, customer-app provisioning, backup orchestration, and deploy all run from version-controlled Ansible playbooks and shell scripts. There are no untracked, manually applied changes on production hosts under normal operation. When something needs to be done, it gets done by running the same play across the relevant hosts. This means changes are reviewable, repeatable and auditable.
WordPress core, plugin, and theme updates:
Customers control their own update cadence by default. While some hosts provide auto-updates, and customers are free to enable the built-in auto-update feature in WordPress, we know that on complex sites it’s rarely safe to assume updates won’t break anything in production. Instead, we make it easy to test updates on staging first to make sure customers can safely apply updates to their live sites at the cadence they wish.
Plugin vulnerability note:
WordPress plugins are written by thousands of independent developers, and we can’t patch the entire ecosystem’s code. What we can do is tell you quickly when a vulnerability is found. We surface known vulnerabilities from vulnerability databases we use on a daily basis, but that doesn’t mean a patch will be available since that’s up to the plugin’s maintainer. We do let you see what we see, and it’s up to you to disable or patch the plugin in order to maintain a secure environment.
Data handling & privacy
Encryption:
All customer-facing traffic (front-end, admin, SFTP, control panel) is served over TLS 1.2 or higher, with TLS 1.3 the dominant connection protocol in practice. HTTP traffic is redirected to HTTPS at the edge.
HTTP Strict Transport Security (HSTS):
HSTS is enabled across the platform with includeSubDomains and preload directives, instructing browsers to refuse plaintext connections to TangibleXP-hosted sites for the duration of the cached policy.
Encryption at rest:
While we can provide full disk-level encryption for customers whose requirements depend on it as part of a custom engagement, this would impact performance without realistically having a security impact given that the scenarios where disk encryption would matter involve physical access to disks whereas attacks on WordPress sites are virtually always remote.
A common follow-up question is whether we keep application secrets like WordPress database credentials, and SMTP passwords, in a separate encrypted secrets store. For the application secrets that matter most, doing this would be theater rather than defense: WordPress requires database credentials to be readable in plaintext from wp-config.php at runtime, and Postfix requires the SMTP password in its config the same way. Encrypting these in a vault would only mean decrypting them on every server boot back into the same plaintext location the application reads from. The effective attack surface doesn’t change. We’d rather be honest about that than dress it up for a checklist.
The protection that disk-level encryption-at-rest actually offers is mainly against physical compromise of provider hardware, like someone breaking into a datacenter and stealing a drive out of the server running your site, which our IaaS providers control through their own data-center physical security. That risk sits well behind a long list of higher-probability attack surfaces we focus on first: edge filtering, application isolation, vulnerability scanning, backup integrity, and account access controls.
We can walk procurement teams through this tradeoff. For customers whose contractual requirements treat encryption-at-rest as a hard line, we can prioritize it as part of a custom engagement.
Data residency:
Your live site runs in the region you select for your application. We don’t make formal data-residency commitments at the standard plan tier as our backup, staging, and CDN systems are designed for out-of-the-box reliability and performance, which means they may span regions. If your organization has a hard residency requirement (a regulator or contract that mandates data stay in a specific country, end to end), we can assist with this as part of a custom engagement.
What we collect, and what we don’t:
We collect the minimum information needed to provision and operate your hosting account: business contact details, billing metadata (your name, email, and Stripe customer/subscription identifiers, never raw card data, which is processed directly by Stripe not stored on our servers), and operational logs. We don’t sell, share or analyze your end-user data. Your site visitors are your data, not ours.
Log retention:
Server access logs, error logs, and application-level audit logs (admin actions, SFTP sessions) are generally retained for at least 30 days for troubleshooting and security investigation, and then deleted. Customers with longer retention requirements can request extended retention as part of a custom engagement.
Account deletion:
When you cancel or miss a payment, we keep your data for at least 30 days in case you change your mind or need to extract anything you missed. After that, we delete the site, files, databases, and backups on a rolling schedule.
Backups & Recovery
Snapshots:
Customer files and databases are backed up as ZFS snapshots with LZ4 compression. Snapshots run daily, unless you change that setting in the dashboard or via a custom engagement with us.
Retention:
We retain 30 days of point-in-time snapshots, beyond which older snapshots are automatically pruned.
Off-site copies:
Backups are replicated to off-site backup hosts in a separate region from the primary site, run on different infrastructure
On-demand backups:
You can trigger a snapshot manually from the dashboard to have a restore point before any changes you’d like to be able to roll back from, like plugin updates, content imports, theme switches, migrations, etc.
You can pull your own backups:
Customers can export a current backup from the control panel at any time.
How fast we can restore:
A typical site restore from the most recent snapshot completes in seconds as ZFS rolls the filesystem back atomically rather than copying files.
What we don’t promise:
We don’t currently publish recovery time objective (RTO) or recovery point objective (RPO) as that strategy needs to be dialed in for each site. As part of a custom engagement, we can set up rapid failover and recovery options such as having replica servers ready to go if one fails. As each replica would cost as much as what we charge for the primary site, that’s a custom-tier conversation and not a cost we force on people who don’t need it so we can keep our hosting plans the best value available.
How we handle incidents:
We’re a small team, so when something breaks you’ll hear from a human who actually understands what happened, not a status page that says “we’re investigating” for a few days.
Detection:
We run a Prometheus + Grafana Agent monitoring stack across every host, exporting metrics every five minutes for Uptime, error rates, response time, and resource usage.
Response:
Our on-call engineer is paged on any platform-level alert. For incidents that affect customer sites, we contact customers quickly after confirming the incident.
Communication:
We directly message affected customers, and for true platform-wide incidents may post about it in the dashboard or tangiblexp.com website.
Postmortems:
While most incidents are upstream providers like ISPs and global infrastructure like CloudFlare we don’t control, for incidents that impact our customers that stem from infrastructure or software we do control we can share a postmortem upon request. For outages that are disruptions outside our services, we can redirect you to the status pages and postmortems posted by the relevant teams at the major tech companies involved.
What we don’t have:
We don’t have a 24/7 staffed NOC. Our on-call rotation covers nights and weekends but we’re a small team. If you need round-the-clock incident responses with a contractually-bound response SLA, we can set up a custom engagement but that kind of staffing will far exceed the pricing we currently offer.
Subprocessors
The companies that touch your data, by category:
| Subprocessor | What they do | Where data sits |
| Cherry Servers, DigitalOcean, OVH | Bare-metal customer site hosting (Cherry Servers, OVH); control plane and backup infrastructure (DigitalOcean) | Canada and US (customer-selected) |
| Cloudflare, Inc. | Network security, WAF, DDoS protection, CDN | Global edge network |
| Stripe | Payment processing and billing | Per Stripe’s published policy |
| Postmark | Transactional email to customers | Per Postmark’s published policy |
| Bento | Customer lifecycle and marketing email | Per Bento’s published policy |
| Referly | Referral program | Per Referly’s published policy |
| Slack | Internal team communications; receives some operational alerts that may reference customer accounts or site identifiers | Per Slack’s published policy |
| Google Analytics 4 | Web analytics on tangiblexp.com (marketing site visits only; does not run on customer-hosted sites) | Per Google’s published policy |
About bare-metal hosting providers:
We deliberately use more than one bare-metal provider so we can put each customer on infrastructure that actually fits their region, plan, and performance profile. Which specific provider hosts a given customer website depends on region availability, the products that provider offers in that region, and current capacity. We can’t guarantee which provider is used given we don’t control availability of products, especially with supply constraints in the current market.
Reporting a vulnerability
If you think you’ve found a security issue affecting TangibleXP or a site we host, we want to hear from you.
Email: [email protected]
What helps us:
- A clear description of the issue and how to reproduce it
- The affected URL or system
- Your contact info so we can follow up
- Time for us to respond before public disclosure (we aim for an initial response within two business days)
What we ask:
- Don’t run automated scans against production sites without coordinating with us first
- Don’t access, modify, or download data that isn’t yours
- Don’t publicly disclose the issue until we’ve had a reasonable chance to fix it
We don’t currently run a paid bug bounty program, but we’ll publicly credit researchers who report in good faith if they want the credit.
Compliance & audits
We don’t carry SOC 2, ISO 27001, HIPAA, or PCI-DSS attestations. These frameworks are useful when it comes to certain buying processes but carry a large cost without necessarily moving the needle on real-world security. We<d rather spend that budget on the things that actually keep your site up, performing optimally, and your data safe. Our Terms of Service reflect this; we don’t make compliance guarantees we can’t back up.
That doesn’t mean we can’t host regulated workloads. It means those workloads need to be handled through custom engagements.
If you need formal compliance support, we offer it as a paid engagement. That includes:
- Custom Data Processing Agreements (DPAs) negotiated to your requirements
- Security questionnaire responses (the long ones like SIG, CAIQ, vendor-risk questionnaires)
- Evidence packages mapped to specific frameworks (SOC 2 control mappings, HIPAA technical safeguards, etc.)
- Custom backup, retention, or audit-log configurations beyond our standard offering
- BAA signing where applicable, with the underlying configuration to support it
This is real work. A typical compliance-support engagement is a multi-week or multi-month project with a five-figure starting price, and we’ll only take it on if we believe we can genuinely meet your requirements.
If that’s a conversation you need to have, contact us and tell us what framework or auditor you’re working with.
Verify any of this yourself
We’d rather you confirm what we say than take our word for it. A few things you can check from outside:
- SSL/TLS configuration: run any TangibleXP-hosted domain through SSL Labs
- CloudFlare in front of every site: check the response headers. You’ll see clouflare / cf branded responses on every request.
- SFTP rejects passwords: try connecting with a password to your SFTP endpoint. It will refuse.
- HSTS, CSP, and security headers: check any TangibleXP site at securityheaders.com
If any of these don’t match what we describe here, we want to know.
Contact
For security questions, compliance and procurement, or general support, contact [email protected].
This page was last updated on May 12th, 2026. We update it when our practices change.