Protecting data.
Data protection starts with policy.
It is policy that mandates people's behavior,
and, of course, policy also will be enforced through the contracts
we have in place with a cloud service provider.
Policy also indicates who is accountable, in other words, who is the owner.
It will mandate that we must follow certain handling requirements, procedures.
The idea of policy is that it provides the authority for the function.
It establishes the fact that the organization has recognized the
importance of something and, of course, is therefore compliant
with things like laws and regulations.
It requires compliance with the procedures as well
and will quite often indicate, when it comes to data,
what is the retention period based, as we saw earlier,
on business requirements and legal requirements.
We looked at before an important part of all this is that
data quite often goes between systems, departments,
and we can say it can show up in a system here and a report
over there or can go out to an external party,
and so it's important that we know where we are actually using our data,
the location, and what are the uses,
why do we even have that data? We map out the data flows.
Maybe, for example,
we even put in a matrix that shows all of our data elements and where
they actually get used. It's important also that we ensure data is in
a consistent format to prevent mistakes and errors that come from
date fields being different, for example. Do we do day/month/year,
month/day/year,
year/month/day? It's very difficult sometimes when we see
something like 12/3 to know whether or not that's the 12th
of March or the 3rd of December, for example.
So normalization is often used to try to keep data in a standard format,
but also to prevent things like duplication of data when we
look at something like a database as well.
When we look at standard formats,
it's a mistake that even I made years ago working on a system where I saw
that customer account numbers were always seven digits,
and so I built my application for a seven‑digit account number.
But I didn't realize that the standard for the organization was nine,
and that is where it would have been better if we had a data dictionary
that said this is the correct format for that type of a field so we don't
end up with a problem sometime in the future where on one system it's
defined differently than on another.
When we look at data, we, of course, have both structured and unstructured data.
Structured data is something with a defined structure,
a database schema, for example, that says this is the address field,
it's 30 characters long,
it's alphanumeric, this is a date field, and this is the format of
that, very defined structures and easy to organize,
for example, in a relational database.
We can also set up an index based on defined keys,
the primary key, the foreign keys, so it's easy to be able to look up,
say,
a certain customer record based on the defined field
of the customer account number.
We, though, also combine many different data sources together into,
for example, a data warehouse.
A data warehouse takes input from many different data sources
and combines or aggregates it together.
And this is where we'll often do normalization as well to make sure that the
data that's coming in is all in the correct same format at least so that we
don't end up corrupting the data in our data warehouse.
Structured data is easy to do analysis of and to be able to look for trends,
patterns, and deviations, for example.
But the problem is a lot of our life is unstructured,
and we have unstructured data, which is undefined.
You take, for example, in an email,
an email is a good example of semi‑structured data
because you have the metadata who it's to,
from, the date, and so on, but then you have the body of the email,
which is just a jumbled collection of words.
And those are unstructured, so the body of the email is unstructured data.
And some of our good analysis and analytics today is based
on doing analysis of individual words,
but also individual words within their context and within
the content of where they're being used.
This works a lot towards things like advertising, for example.
We also have, of course,
in today's world a type of data warehouse we know as big data,
the collection of massive amounts of unstructured data
rather than just relational databases, and so on,
as we had with the former data warehouses.
When we look at semi‑structured data,
it's data that does not have a rigid schema.
This is a name field, this is a numeric field,
for example. And for that reason, it doesn't fit well into that
structured data necessary in a relational database.
Examples of this can be something like XML, where with Extensible
Markup Language, we actually have a field that we then define what
that field represents so that it can be then moved from an
unstructured hopefully into a structured sense.
Another example of this, for example, is comma‑delimited fields,
CSV files, and emails as we looked at before,
a combination of both structured and unstructured data.
We need to know when we have intellectual property to
ensure that those intellectual property pieces of data are
also appropriately protected.
Things like patents, and copyrights, trademarks, and trade secrets.
So when we're looking at data,
it's not just about privacy of personal information,
but often it's about things like secrecy of maybe
some research we're dealing with,
protection of our trademarks and our copyrights to make sure
that nobody else is just stealing our ideas,
but this requires us to identify the things that are
important that need to be protected,
and, of course, then to provide them the appropriate level of protection.
The key points review.
We don't want to spend a lot of money to protect something of little value,
so the protection we give to our data is based on its value.
But this requires that we clearly know who makes that determination of value,
the owner,
what are the levels of classification and handling for that data, and to
make sure we also protect intellectual property as well.