Data Security Lifecycle 2.0: Functions, Actors, and Controls

By Rich

In our last post we added location and access attributes to the Data Security Lifecycle. Now let’s start digging into the data flow and controls.

To review, so far we’ve completed our topographic map for data:


This illustrates, at a high level, how data moves in and out of different environments, and to and from different devices. It doesn’t yet tell us which controls to use or where to place them. That’s where the next layer comes in, as we specify locations, actors (‘who’), and functions:

Functions and Controls


There are three things we can do with a given datum:

  • Access: View/access the data, including copying, file transfers, and other exchanges of information.
  • Process: Perform a transaction on the data: update it, use it in a business processing transaction, etc.
  • Store: Store the data (in a file, database, etc.).

The table below shows which functions map to which phases of the lifecycle:

Functions Table

Each of these functions is performed in a location, by an actor (person).


Essentially, a control is what we use to restrict a list of possible actions down to allowed actions. For example, encryption can be used to restrict access to data, application controls to restrict processing via authorization, and DRM storage to prevent unauthorized copies/accesses.

To determine the necessary controls; we first list out all possible functions, locations, and actors; and then which ones to allow. We then determine what controls we need to make that happen (technical or process). Controls can be either preventative or detective (monitoring), but keep in mind that monitoring controls that don’t tie back into some sort of alerting or analysis merely provide an audit log, not a functional control.

This might be a little clearer for some of you as a table:

Controls Table

Here you would list a function, the actor, and the location, and then check whether it is allowed or not. Any time you have a ‘no’ in the allowed box, you would implement and document a control.

Tying It together

Functions and Cycle

In essence what we’ve produced is a high-level version of a data flow diagram (albeit not using standard programming taxonomy). We start by mapping the possible data flows, including devices and different physical and virtual locations, and at which phases in its lifecycle data can move between those locations. Then, for each phase of the lifecycle in a location, we determine which functions, people/systems, and more-granular locations for working with the data are possible. We then figure out which we want to restrict, and what controls we need to enforce those restrictions.

This looks complex, but keep in mind that you aren’t likely to do it for all data within an entire organization. For given data in a given application/implementation you’ll be working with a much more restrictive subset of possibilities. This clearly becomes more involved with bigger applications, but practically speaking you need to know where data flows, what’s possible, and what should be allowed, to design your security.

In a future post we’ll show you an example, and down the road we also plan to produce a controls matrix which will show you where the different data security controls fit in.

No Related Posts

I feel like I understand it but then I actually find the table quite confusing (or I just totaly don’t get it). How would you fill this out as an example?

“Here you would list a function, the actor, and the location”. So e.g. this could be
Function: Access
Actor: Employee
Location: External Smartphone

These would basically replace the three headlines. But what would I know actually fill into the cells of the table?

Or do functions, actor and locations go into the cells? But how would this fit with having a possible/allowed three times?

Some example would be really helpful.

By Matthias


I’m liking the approach, and the next level of detail really helps flesh out the details. As a thought experiment, I tried mapping a system we have in the office, and I ran into a problem.

Essentially, we have an application that is available over the internet, but administered internally. Everyone logs in through the same gateway, but ‘administrative’ functions (i.e. changing access privileges etc.) are only available from the internal network.

What I can’t seem to map is the function ‘administer users’, the location ‘internal network’, and the population ‘admins’ into the chart such that the control ‘must be on internal network’ makes sense.

Any suggestions?

By Bluesheep

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.