A Service Provider That Protects Its Own Infrastructure · Objective Criteria in Cyber Security Procurement
A professional situation assessment backed by passive reconnaissance data from 87 service providers · objective criteria to assist the buyer's selection process within the framework of Europe · Asia · the Middle East · North America · GDPR · KVKK · CCPA · LGPD · POPIA · and the transparent practices DSET applies to its own infrastructure.
A Service Provider That Protects Its Own Infrastructure
There is a question frequently asked during cyber security service procurement processes: "How do we measure the security maturity of the firm that will work with us?" One of the easiest and free answers to this · is to look at how the service provider manages its own digital assets. Because the discipline an organization applies in its daily operations · is a realistic indicator of the assurance it can offer its customers.
This article is not a critique · it is a situation assessment that summarizes patterns observed across the industry and supports them with measurable data. No firm names are shared. The aim is not to single out an individual target · but to highlight objective criteria that can assist the buyer's selection process.
A Passive Reconnaissance Study
Using the passive reconnaissance module of our KAOS engine · we scanned the main domains of 87 organizations that are authorized in their market and offer cyber security · pentest · and data protection consultancy. The geographic distribution was kept broad: Europe · Asia · the Middle East · North America. Only the externally visible surface was assessed. No active testing · no unauthorized access attempt was made. Data visible with a standard browser and the curl command has been summarized. The same results are reproducible by anyone.
| Finding | Number of Firms | Rate |
|---|---|---|
| Uses WordPress | 61 | 70.1% |
| Admin panel open to the internet | 54 | 62.0% |
.env or .env.production externally accessible |
12 | 13.7% |
.git/HEAD or .git/config downloadable |
19 | 21.8% |
| No rate limit detected on the login page | 73 | 83.9% |
| No HTTPS or TLS 1.0 / 1.1 supported | 9 | 10.3% |
| No Privacy Notice or broken link | 41 | 47.1% |
| Data Controller declaration not detected | 58 | 66.6% |
| HTTP Security Headers missing | 78 | 89.6% |
| Stack disclosure observed | 66 | 75.8% |
The majority of these figures · stem most often not from a conscious choice but from structural reasons such as operational prioritization · time · workload. For a rapidly growing firm, customer projects always take precedence · while the regular maintenance of its own infrastructure may fall behind. This is a human and understandable picture. A shared responsibility of the industry · is to make the processes and tools that ease this maintenance more widespread.
On WordPress and Other Off-the-Shelf Platforms
Popular content management systems such as WordPress · Drupal · Joomla are not bad software. In the right hands · with strict configuration · with regular updates · they can be operated securely. The element that creates risk is not the platform itself · but operational discipline:
- An un-updated core · themes · plugins.
- Off-the-shelf themes containing unknown third-party dependencies.
- An attack surface that expands with the parallel use of many plugins.
xmlrpc.phpand enumeration endpoints left open.- Admin panels without rate limiting · 2FA · IP whitelisting.
According to the Patchstack 2025 report · 96.8% of WordPress-originated breaches are plugin-based. In our DSET MDR logs · the average daily brute · force attempt count against WordPress login pages exceeds 17,000 per firm. These numbers show not that the platform should be rejected · but that when chosen it should be managed with a serious hardening process.
Secret Management in Source Code
Similar phenomena can also be observed in organizations using a modern stack. Typical finding types encountered in OSINT scans we have conducted recently:
- Cloud provider access keys left as hardcoded strings in public repositories.
- Third-party API keys appearing in plain text in client-side bundles.
- Configuration files accessible in the site root.
- Forgotten staging environments on subdomains.
These patterns stem not from malice · but from the absence of sufficient secret scanning automation in CI/CD processes. Integrating open source tools such as gitleaks · trufflehog into the pipeline · can be enough to catch the bulk of the problem early.
Continuity in Data Protection Compliance
In a portion of the 87 organizations examined · documents such as the Data Controller declaration · Privacy Notice · Cookie Policy were observed to be missing · out of date · or as broken links. This picture · stems less from the firms' lack of compliance capacity than from compliance documents being handled as a one-time deliverable rather than as a living process.
GDPR (EU) · KVKK (TR) · CCPA (California) · LGPD (Brazil) · POPIA (South Africa) highlight a common framework: data protection compliance is a living process. The Privacy Notice · ROPA · DPO duties · the DSAR procedure · breach notification processes must be regularly updated and audited. A firm that can continuously operate this discipline within its own organization · can carry that same continuity to its customers.
The Practices DSET Applies to Its Own Infrastructure
While sharing the industry picture, it is appropriate to set out our own practice with transparency. The controls applied in the DSET infrastructure are as follows:
1. A Custom-Built Stack
Our website does not run on an off-the-shelf CMS · but on a server-side rendered architecture written in TypeScript by the DSET Engineering Team. All dependencies pass through an automated security scanning pipeline · an automatic PR is opened when a CVE is found · and npm audit is triggered on every commit.
2. Centralized Management of Secrets
No API key · database password · or signing key resides in the source code. All are managed through environment variables + secret management. .env files are within the scope of gitignore. The gitleaks and trufflehog scanners run on every push.
3. HTTP Header Hardening
Headers that disclose the stack have been disabled. There is no X · Powered · By. HSTS · Content Security Policy (nonce-based) · Permissions Policy · X · Frame · Options · Cross · Origin · Embedder · Policy · Cross · Origin · Opener · Policy are actively configured.
4. Honeypot and Early Warning Layer
Classic paths such as /wp · admin · /phpmyadmin · /.env · /.git do not exist in our system; they are declared as Disallow via robots.txt. Probing these surfaces acts as a WAF trigger · the IP is logged · and fail2ban rules are activated.
5. Multi-Jurisdiction Data Protection Compliance
- The Privacy Notice is current · published in Turkish and English.
- VERBİS registration is complete under KVKK (TR).
- A DPO is appointed and a ROPA is maintained under GDPR (EU).
- The data subject rights procedure is documented under CCPA and LGPD.
- An explicit consent checkbox · IP hash (SHA · 256) · and a 72-hour breach notification process are built into the contact form.
- A target of an initial response to a DSAR request within 24 hours is committed to.
- Cookie categories are managed with a separate opt · in mechanism.
6. Responsible Disclosure Channel
Our /.well · known/security.txt file is published to the RFC 9116 standard. Independent researchers can submit vulnerability reports through an OpenPGP-signed channel · with a response committed to within 48 hours.
7. Continuous Internal Audit with the KAOS Engine
We scan our own site every night with our own autonomous analysis engine, KAOS. The engine independently tests our defenses · the findings automatically open an issue · and the team closes it within 24 hours.
Methodological Transparency
All findings in this article were obtained through open source intelligence (OSINT) methods. Not a single rate is an estimate. The table produced by the KAOS passive reconnaissance module · consists of results that any user could reproduce today in a browser tab · with a curl command · or with a whatweb or wappalyzer extension. No finding is behind closed doors. None required unauthorized access. No firm's identity has been shared.
The aim of this article is not to confront the industry · but to support the buyer in having an objective set of criteria during the selection process.
Checklist for the Buyer
Before working with a cyber security service provider, the following questions offer a valuable opportunity for a quick scan:
- Are surfaces such as
.env·.git· the admin panel closed on the service provider's own site? - Are the HTTP security header sets complete and correctly configured?
- Are the Privacy Notice · Cookie Policy · DSAR procedure documented and current?
- Can the Data Controller registration · DPO appointment · ROPA records be shared on request?
- Are regular pentests and red team exercises conducted on its own infrastructure?
- Are the responsible disclosure channels (security.txt · PGP) in working order?
These questions both open a transparent initial conversation with the service provider · and ground the selection process in objective data.
The DSET Approach
At DSET, we adopt as an engineering discipline the practice of applying every control we offer our customers to our own infrastructure first. Our contact channels for measuring your organization's attack surface · having a pentest done · establishing GDPR and KVKK compliance · or initiating a digital forensics response if you have experienced a data breach are below.
+90 536 662 38 09 · WhatsApp and phone · reachable 24/7.
Email: [email protected] · For urgent security reports [email protected] · the PGP-signed channel is active.
The initial consultation is free. An NDA is signed · your case is analyzed within 24 hours · and a quote reaches you within 48 hours.
"An organization that can protect its own infrastructure · is a more trustworthy partner for yours." · The DSET Philosophy
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.