Planning for 2013: cloud, data, and security can no longer be discussed separately

When a company starts a project to move data to the cloud or roll out a new analytics platform, one of two things usually happens. Either security is called in "at the end, to check things over." Or the data question gets deferred until the architecture is already settled and changing anything is expensive.

Both patterns are costly. And from 2013 onward they will cost even more - because regulatory pressure is building, incidents are becoming public, and the price of a design mistake no longer dissolves into "we will fix it later."

Why these three topics have merged

A few years ago it was still possible to keep IT infrastructure, data management, and information security as three separate departments. Each with its own budget, its own vocabulary, and its own priorities.

The cloud broke that. When data leaves the perimeter - to a provider, into a SaaS service, into a partner's API - the boundary of responsibility no longer coincides with the network boundary. The architectural decision of "where to store data" automatically becomes a security decision. And the reverse is equally true: a security rule saying "this cannot be stored externally" directly shapes the architecture.

Data is the common foundation for both. Without understanding what is actually stored, where it comes from, and where it goes, neither architecture nor protection can be designed correctly.

What happens when the conversations stay separate

I have seen projects where a team spent months building a clean cloud architecture, and then at the final stage the security team said: "this cannot go live - customer personal data cannot be processed outside the jurisdiction." The project was redesigned almost entirely.

I have seen the opposite too: a security team blocked data flows between systems so thoroughly that analytics became physically impossible. Not from bad intent - just rules written without understanding how the data is used.

This is not a people problem. It is a structural problem with how the conversation is organized.

What joint planning should look like

At the start of any project where data moves somewhere, or where an external boundary appears, three blocks of questions need to be asked at the same time:

On architecture: where will the data physically live, which components will process it in motion, what dependencies on external services will appear?

On data: what exactly is this data, does it include personal or sensitive records, who owns it and who is responsible for its accuracy?

On security: which of this data is subject to restrictions, who has access rights at each stage, what happens in the event of an incident and who finds out first?

The answers to these questions affect each other. That is why they need to be discussed in the same room.

Practical steps for the 2013 plan

If your company has projects planned for next year involving data migration, new cloud services, or partner integrations, a few things are worth doing in advance:

• make sure a security specialist is included in design from the beginning, not invited to the acceptance review;
• do a quick audit of what data is stored where today - not to rebuild everything, but to know what you are working with;
• document which categories of company data must never leave the perimeter under any circumstances - that is a boundary the architecture is obliged to respect;
• review cloud provider contracts: where the servers physically sit, what breach notification obligations exist, and what happens to your data when the contract ends - I looked at what SLAs actually say and do not say in public cloud SLA: what it says and what it does not, and at how to think about the exit before you enter in vendor lock-in: think about the exit before you enter the cloud.

This is not paranoia and not bureaucracy. It is basic project hygiene that in 2013 stops being optional.

One diagnostic question

Ask anyone in your company: "if we wanted to switch cloud providers tomorrow, what exactly would we need to do?" If nobody has an answer - it means architecture, data, and security have not yet been discussed as a single system. That is worth fixing before the next large project starts, not in the middle of it.