Regulatory Compliance (ISO, PCI-DSS, etc.)
Regulatory compliance support: meeting the infrastructure requirements of ISO 27001, PCI-DSS, data protection law and industry regulations, and producing the evidence.
What we deliver
The difference between the standard's requirements and the current state, converted into a to-do list.
Infrastructure controls built to standard: access control, records management, encryption, backup and change management.
We routinely produce the evidence an auditor will ask for: restore records, access review sign-offs, patch reports and exercise results. A control without evidence counts as not implemented.
ISO 27001, PCI-DSS and data protection requirements mapped onto shared controls, so the same work is not done three times.
Preparation before the audit, technical questions answered during it, and a closure plan produced for findings.
Compliance run as a process rather than a project, with periodic checks and reviews placed on the calendar.
How it works
Every engagement follows the same five steps: baseline the current state, design the target model, roll out in stages, operate it, and improve against measurements.
Assess
Baseline the current state, name the gaps and put the success criteria in writing.
Design
Architect the target operating model and the toolchain it needs.
Deploy
Implement, configure and validate in a staged rollout.
Operate
24/7 management with contracted response times and proactive monitoring.
Improve
Continuous improvement driven by metrics, incidents and changes in the business.
Every engagement runs under a written SLA: a commitment, not a best-effort promise.
Dedicated engineers who know your stack. No generalist help-desk tier in between.
Service reviews every two weeks, roadmap updates every quarter.
Who uses this
The industries we run Regulatory Compliance (ISO, PCI-DSS, etc.) for.
The concepts behind this service
- ISO 20000
- The international standard for IT service management.
- BDDK (Turkish banking regulator)
- Türkiye's Banking Regulation and Supervision Agency.
This section explains the technical terms used on this page. The definitions come from Eclit's own technology glossary, and each term links through to its full entry there.
The full technology glossary →Knowledge Hub
What we have written about running and managing technology, collected in one place.
01Which security regulations apply to us?
It varies by industry: BDDK and PCI-DSS for banking and payments, health data legislation in healthcare, industry-specific obligations in energy and telecoms, and KVKK across all of them. The first step is establishing which ones apply to you.
02How do you map technical controls to regulation?
We build a control framework and link each regulatory clause to one or more controls. Auditors ask by clause and you answer by control; without that mapping every audit starts from scratch.
03What should our log retention period be?
Start from the statutory minimum and add what incident investigations need. Long retention is costly, and short retention cannot show when an incident began; we find the balance through measurement.
04How often should penetration testing be done?
It varies by regulation; PCI-DSS requires it annually and after significant change. Beyond that, it makes sense to repeat the test after any major architectural change: last year's test did not test this year's architecture.
05Who is responsible for closing findings?
Technical fixes within scope sit with us; findings in application code sit with the development team. Every finding gets an owner and a target closure date: an unowned finding does not get closed.
Let's work out where to start
Within two weeks you get it in writing: what works, what carries risk, and a prioritized roadmap.
Request a conversation