1. What this page covers
This page covers two distinct scopes, which we keep clearly apart:
- This website: the marketing site at mantek.io you're reading now.
- Client engagements: the security posture we bring when we design, build, and operate WordPress and web systems for clients, from business websites to the high-traffic platforms newsrooms, broadcasters and publishers run on.
What this page is not. It is not a certifications page. ManTek does not hold SOC 2 or ISO 27001 certification today. Where this page references a framework, we say whether we align with it (design controls to its standard) or are certified for it (independently audited against it). We do not claim audits we do not have.
Some engagement-specific details (concrete RTO/RPO numbers, sub-processor lists for individual projects, breach-notification SLAs) are agreed contractually per engagement and are not published here.
2. Our security commitment
Security is a design constraint, not a layer we add late. The publishing systems we build need to be calm under pressure: the day a story breaks is exactly when both performance and security have to hold. Those two requirements are not in tension when the architecture is right.
We will be honest about what we do, what we don't do, and where we are improving.
3. Infrastructure
This website.
mantek.io is a static site delivered through Cloudflare Pages, fronted by the Cloudflare global edge network. There are no origin servers we operate, no database, and no user accounts. The only piece of dynamic processing is a Cloudflare Pages Function that receives the contact-form submission and forwards it as an email via Resend.
This website is protected by Cloudflare's WAF and DDoS protection at the edge. TLS is terminated at the edge using TLS 1.3 (TLS 1.2 is supported for older clients). DNS is also served by Cloudflare.
Client engagements.
The default cloud is AWS. Region selection is driven by the client's data-residency requirements and audience geography. We architect for VPC isolation, with public-facing components (CloudFront, load balancers) separated from private compute (Lambda, ECS, EC2 in private subnets) and private data stores (RDS, ElastiCache, private S3). Cross-account isolation is used where blast-radius separation between environments matters.
4. Encryption
In transit.
All traffic served from mantek.io and from systems we architect for clients is encrypted in transit using TLS 1.2 or newer. Internal cross-service traffic within client AWS environments uses VPC endpoints and TLS where applicable.
At rest.
We rely on AWS-native encryption for client systems: S3 server-side encryption (SSE-S3 or SSE-KMS depending on data classification), EBS encryption for compute volumes, encrypted RDS / Aurora storage, and AWS KMS for key management. Encryption is enabled by default and verified in our deployment checks.
Secrets.
Credentials and keys are never committed to source-controlled files. We use AWS Secrets Manager and AWS Systems Manager Parameter Store (KMS-encrypted) for runtime secrets; rotation policies are defined for long-lived credentials.
5. Identity & access
We follow the principle of least privilege across systems we control and recommend the same for client environments. Administrative access requires multi-factor authentication. We do not use shared admin credentials.
Where we hold delegated access into a client's AWS environment, we use IAM roles with assume-role and external-ID protections rather than long-lived access keys. Access is time-limited to the scope of the engagement and removed when the engagement closes. Administrative actions are logged and auditable.
6. WordPress hardening
This is core to what we do, so we'll be specific.
Versions are pinned.
We pin WordPress core, plugins, and themes to known-good versions and roll updates through staging before production. We do not auto-update plugins on production sites.
Plugins are vetted before adoption.
Before we put a plugin in a client build, we review its code quality, dependency tree, maintenance cadence, and security history. We prefer fewer, well-maintained plugins to a long sprawl.
Read-only / headless where appropriate.
For high-traffic newsroom delivery, we separate the editorial WordPress instance from the front-end that serves readers: a static or CloudFront-backed read path that does not expose the WordPress runtime to the public internet.
WAF in front.
WordPress sites are served behind Cloudflare or AWS WAF with managed rules for WordPress-specific attacks. Admin paths are rate-limited and, where the engagement allows, IP-restricted.
XML-RPC and similar exposures.
XML-RPC is disabled by default and re-enabled only when a
specific use case requires it (e.g., Jetpack). The default
xmlrpc.php endpoint is not exposed publicly otherwise.
Strong credentials and MFA on admin accounts.
Admin accounts require MFA. We do not ship sites with the default
admin username, and we enforce strong password policies.
File integrity monitoring and patching cadence.
Production WordPress installations log file changes; unexpected modifications trigger alerts. Security patches are applied within defined windows, and critical patches are applied out-of-cycle.
7. Secure software delivery
All code we author or modify lives in version control with code review required on changes. Pull requests are scanned for dependency vulnerabilities and committed secrets. Builds and deployments are reproducible. Releases move through development, staging, and production environments before reaching end users.
8. Monitoring & incident response
Application and infrastructure logs are centralised (Amazon CloudWatch, or the client's equivalent) and retained according to the engagement's compliance needs. Anomalies and errors are alerted to the on-call channel.
If we identify or are notified of a security incident affecting a client system, our response approach is identify → contain → eradicate → recover → review. We notify the affected client without undue delay and assist them in meeting their own regulatory notification obligations.
For incidents involving personal data, we operate to the 72-hour breach-notification standard set by the UAE PDPL and the EU GDPR.
9. Backups & business continuity
For client systems we operate or co-operate, backups are versioned, encrypted, and stored outside the primary blast radius, often in a separate AWS account or region. Backup retention and restore-time targets are agreed per engagement.
Restore testing is part of go-live and is repeated at intervals appropriate to the engagement. Disaster-recovery posture (active-passive vs. active-active, RTO and RPO targets) is scoped per engagement and documented in the engagement's runbooks.
10. Privacy & data protection
How this website handles personal information (what we collect, who processes it (Cloudflare, Resend, Zoho), how long we keep it, and the rights you have over it) is set out in our Privacy Policy.
For client engagements that process personal data, we sign a Data Processing Agreement (DPA) under the UAE PDPL and, where the engagement involves EEA data subjects, the EU GDPR. Engagement-specific sub-processor lists are disclosed and agreed at signing.
We do not use data we process on behalf of clients for any other purpose, including the training of machine-learning models.
11. Vulnerability disclosure
If you have found a security issue on this website, in a system you believe ManTek operates, or in code we publish, please tell us.
- Email: security@mantek.io
- Acknowledgement: within 5 business days.
- Initial assessment: within 10 business days.
Safe harbour.
We will not pursue, or recommend, legal action against security researchers who:
- act in good faith;
- do not perform destructive testing or data exfiltration beyond a minimal proof-of-concept;
- do not access, modify, or destroy data belonging to third parties;
- do not publicly disclose the issue before we have had a reasonable opportunity to remediate it (typically 90 days, sooner if the issue is already being actively exploited).
ManTek does not currently operate a paid bug-bounty programme.
12. Standards & frameworks
ManTek does not currently hold SOC 2 or ISO 27001 certification. We design and operate controls that align with widely accepted information-security frameworks:
- SOC 2 Trust Services Criteria informs our control design for security, availability, and confidentiality.
- ISO/IEC 27001 informs our information-security management practices.
- OWASP Application Security Verification Standard (ASVS) and OWASP Top Ten inform our application security controls.
- CIS Benchmarks inform OS, container, and AWS baselines where applicable.
We will formalise a compliance programme as ManTek and the engagements we support grow. We will not claim certifications we do not hold.
13. Changes to this page
We may update this page from time to time, for example, when we introduce a new control, formalise a programme, or change our hosting arrangement. The "Last updated" date at the top will always show when we last revised it.
14. Contact
Security reports and questions: security@mantek.io
Privacy enquiries and data-rights requests: privacy@mantek.io
General enquiries: info@mantek.io