At yesterday’s Data Retention Workshop we discussed a range of common service scenarios we are dealing with that we found are not properly explained by the material that has been published by the AGD. I felt that it was important to capture the results of the workshop and share the information with the Service Provider community.

The goal of these blog posts is to provide some high level indications of how I believe Service Providers should interpret their obligations in these contexts.

What is my approach to determining DR obligations?

In general, we are taking the following steps to determine what our obligations are from a “product we sell perspective”.

1. Work out what it is you sell to your customers. Draw a diagram, or anything else that will help you understand all the aspects of what you do. Try and make this as detailed as possible.
2. Work through your diagram to determine what are the “relevant service(s)” in your product. We aren’t going to go into great lengths to define what this is in this post.
3. Work out if there are any relevant exclusions for your “relevant service(s)” that would mean that they are “not relevant” for the purposes of data retention.

Once you’ve completed these, your process to assess your obligations and develop a compliance plan (which is part of your DRIP) is pretty straight forward:

1. Work out what data you need to collect to meet your obligations. Try and do this ignorant of what data you currently collect.
2. Work out what data you currently have available to you. This is probably a subset of the required dataset.
3. Work out what you need to do to create/generate/record any additional information you need and how long it’s going to take you to get there. Make sure it’s less than 18 months!
4. Record this information in your DRIP.

We won’t go into this level of detail in this post, but I’ll aim to publish some information about what you might need to consider around individual services over the coming weeks.

The Managed WAN Scenario

One of the most common scenarios we are asked about is a Managed WAN. This is a good starting point to consider some of the intricacies of your Data Retention obligations as it covers a range of services. For the purposes of this exercise, we are going to take the viewpoint that the person assessing their obligations is the “Layer 2 Network Operator”. This means we are going to assume that the “internet” service is provided by them, that they own the MPLS infrastructure, and that they are also the provider of the PSTN connectivity for the phone system.

Step 1. Diagram out the service

We’ve done this already. It’s important to identify the possible places that you might have Data Retention requirements so that you can properly self-assess what you need to do.

Step 2. Determine the Possibly Relevant Services

In this scenario there are a number of possibly relevant services. At this point it might be tempting to start excluding services because you think they might be relevant, or looking at individual services and asking a lot of “what if” style questions. They key thing is “what do you sell” and “could we potentially have an obligation around it”.

In this diagram the potentially relevant services we have:

1. Internet Access Service
2. Comms links to site (via a variety of technologies)
3. The “MPLS WAN bit”
4. The routers at each site
5. The “LAN” and “Voice” networks on each site
6. The edge “firewalls”
7. The VPN servers
8. The SIP connectivity
9. The PSTN connectivity
10. The PBX(s)
11. The Application Servers

For each of these services we need to consider whether or not these potential “services” is in fact going to be subject to data retention obligations.

Step 3. Determine if there are any relevant exclusions for the service

Generally speaking there are two exclusions which are going to apply – an exclusion for the supply of services in “the same area” and an exclusion for the supply of services to a Person(s) “immediate” circle.

Internet Access Service
This service is definitely relevant, and no exclusions would apply.

Comms links to site(s)
These are tricky. In this scenario, the comms links to sites are not “internet access services” and are services to support the supply of services to a Person(s) immediate circle. In my view, that means that in the situation where you are providing a Corporate WAN, there is no data retention obligations for the individual links that connect the WAN into your MPLS network.

The “MPLS WAN bit”
In our opinion this is not a relevant service, even though it is part of the carriage of communications. If you believe that this is, in fact a service, then the same exclusion we apply for the comms links would apply in this scenario.

The routers at each site
I would consider that we can safely rule these out for two reasons:

• We have already ruled out the Comms links to the individual site(s) as not relevant because they are providing service(s) to the Person(s) immediate circle.
• Even if the Comms links were in scope, what goes on behind the routers would be irrelevant, so in considering the comms links we are going to capture any relevant data.

The “LAN” and “Voice” networks on each site
For the same reasons as we exclude the routers we can safely exclude the LAN. Specifically, we are applying both the “same location” exclusion and the “immediate circle” exclusion here.

The edge “firewalls”
These are perhaps more tricky. I’ll start by saying that I don’t believe that these are relevant in this context because we are already capturing all the relevant data on the internet links for this customer. Assuming that you are performing NAT on the firewalls, it is still a single entity behind the firewalls, and it’s clear that the DR legislation does not require you to track the individual usage of an employee, student, etc. The point of the legislation is to identify the entity that did something, not the individual employee or student that did something.

The possible difference here would be if your firewalls are multi-tenanted. You would need to have enough information to identify who the customer is that performed a particular action. That means that if you share a single public IP address, you are going to need to retain NAT tables to pinpoint down which customer used an IP; but you possibly need/want to de-identify these to hide the actual “IP endpoint” behind the firewall. If each customer had a separate public IP address you probably don’t need to do anything.

Long and short here – in the scenario pictured, excluded/not relevant.

The VPN Servers
A lot is going to depend on how you implement the VPN scenario. If the VPN is single-tenanted (i.e. one VPN public IP address per customer) then it’s probably not relevant. If you multi-tenant your VPN delivery (i.e. one public VPN endpoint that connects customers to different networks on the basis of their credentials or specific URL they hit) then you are going to need to retain logs that are sufficient to place where a user’s connection landed them.

The SIP Connectivity
This is relevant.

The PSTN Connectivity
I’m assuming that there is some sort of “PSTN” or “ISDN” failback. Regardless, this is relevant.

The PBX(s)
Even if you manage these servers, they are used to provide service to an “immediate” circle and so can be considered excluded. You would not be required to retain information about internal calls between endpoints in the same immediate circle. In a Hosted PBX scenario the answer could be different.

The Application Servers
For the same reasons we exclude the PBXs, we are going to exclude the application servers. If these servers were multi-tenanted then the obligations could be different.

This leaves us with the following services we need to determine our data retention obligations on:

1. Internet Service
2. SIP/PSTN Service
3. VPN Services