Regulation is not an obstacle; it is an input to the architecture.

In finance, public sector and healthcare, a cloud decision is regulatory as much as technical. Sanal Çekirdek begins by translating regulatory expectations into technical requirements, and the architecture follows.

No service provider can guarantee compliance; legal responsibility rests with the data controller. A provider's job is to build auditable controls and make the decisions documentable.

Start by translating requirements Back to Data Sovereignty

Translating expectation into requirement

Regulatory texts do not draw architectures; they state expectations. The first task is converting those into measurable technical requirements: within which boundaries data stays, who may reach it, which records are kept.

Each requirement cites the text it rests on
Points open to interpretation go to legal for confirmation
A requirement that cannot be met is listed rather than hidden
Requirements are revisited as regulation changes

Choosing the isolation level

'Private cloud' is not one thing: logical isolation, dedicated hardware and a fully separate environment carry different costs and different levels of control. The choice follows which level the requirement genuinely calls for.

Isolation level can differ per component
A shared management plane is assessed separately
Cost differences are shown per level
The reasoning can be presented during an audit

Access and privilege control

In a regulated environment, who reached what matters as much as the access itself. Administrative access is granted with approval and an expiry; sessions are recorded and those records are stored beyond the reach of whoever accessed.

Administrative access opens on request and approval
Session records are kept where the accessing party cannot erase them
Provider personnel access is inside the same scope
Emergency access uses a separate account and raises a notification

Audit readiness

When an audit arrives, evidence should be presented rather than produced. Records showing that controls operate are generated continuously and reviewed on a regular cycle.

Evidence is produced continuously, not assembled during an audit
Control owners and a review calendar are established
Each finding carries an owner and a closing date
Provider reports are reconciled with your own records

How we work

Translate regulatory expectations into requirements
Choose the isolation level against the requirement
Build access and privilege control
Make evidence generation continuous
Update requirements as regulation changes

How success is measured

Every requirement has a cited basis and a written answer
No standing administrative access remains
Session records are stored independently
Audit requests are met with existing records

Frequently asked questions

Do you guarantee compliance?

No, and we cannot. Compliance is a legal determination and responsibility rests with the data controller. Our work is to build controls that meet the requirements and to show, with evidence, that they operate.

Will our data leave the country?

That is a design decision, written at the start. All data paths including backup, monitoring and support access are mapped; if any flow crosses a border it is stated explicitly.

Can public cloud not be used for regulated work?

It can; what decides is whether the requirement is met, not the hosting model. Some requirements are satisfied in public cloud and some are not, and the call is made per component.

Share the regulations you are subject to; let's start by turning the expectations into technical requirements.

Start by translating requirements