Securing High-Value Records in the Digital Age: Insights from Our Latest Webinar

Duration: 0:58:13

Speakers: Jennifer Chadband, CRM, IGP, CIPP/E, Licensed Attorney, Senior Consultant / Consulting Co-Manager, Zasio; Frank Fazzio, CIPP/US, CIPM, IGP, CRM, Licensed Attorney, Senior Analyst, Zasio; Rick Surber, CRM, IGP, Licensed Attorney, Senior Consultant / Consulting Co-Manager, Zasio; Jerry Manter, Zasio (fielded the audience questions)

Lightly edited machine transcript. Slides are summarized where they carry information not spoken aloud.

Jennifer Chadband: Welcome, everybody, to Virtual Coffee today. Really excited for today's session, and we are actually co-hosting our session today with the local Boise Valley ARMA chapter, so shout out to the BVC ARMA crew joining us today. Really happy to have that partnership here locally.

[Slide: Meet Our Presenters: Jennifer Chadband, CRM, IGP, CIPP/E, Licensed Attorney, Senior Consultant / Consulting Co-Manager; Frank Fazzio, CIPP/US, CIPM, IGP, CRM, Licensed Attorney, Senior Analyst; Rick Surber, CRM, IGP, Licensed Attorney, Senior Consultant / Consulting Co-Manager.]

So we got a great session for you all today, and in case you didn't catch our colleague Frank Fazzio at ARMA just recently, we're happy to have you here for a little bit more discussion surrounding high-value records. It was a hit, so really excited to have Frank with us today. I see a lot of familiar names on here, so that's great. I also see a lot of new ones. If you haven't joined our Virtual Coffee session before, just a little bit of a primer background: first rule of Virtual Coffee is have your beverage of choice, whether it's coffee, hot chocolate, Diet Coke, a little too early for whiskey, but whatever that might be. I don't know, I do see some people on European time, so hey, maybe it's five o'clock there. But first rule is have your drink of choice. And really it's just kind of a forum. We like to keep it casual, conversational amongst colleagues, and we do welcome questions too. We had a few pre-submitted questions that we're happy to answer, and then we will gather as many questions as we can and plan to set aside some time at the end of the hour to go over those.

So that's a little bit about Virtual Coffee, but without further ado, why don't I go ahead and introduce my colleague, Frank Fazzio, who is going to get us started on our conversation, a little bit of background. He'll be walking us through some slides, which we will be sharing. And yeah, really excited to get this conversation started. So cheers, everybody, and I'll hand it over to you, Frank.

Frank Fazzio: Okay, thank you very much, Jen, and thanks for having me on Virtual Coffee. So today we're going to be talking about an important aspect of information governance, and that's the intersection between access to information and minimizing information risk. It's a little bit of a tightrope. If you go too far towards openness, you invite potential disaster, but if you clamp down too hard on minimizing risk, it can stifle growth. But finding the sweet spot, that's really the key to maximizing information's value. And that's kind of what got me into the world of information governance.

Every decision can potentially either safeguard your fortunes or spell disaster. So I want to talk about a critical slice of the information risk pie, and that's the ever-present threat of loss, destruction, or theft of your most valuable information assets. Securing information assets sits on the periphery of what is traditional records management. As records managers, it's not our daily bread and butter. But actually, that's where information security can shine as your secret weapon. It really sits at the crossroads of IT and legal and records management.

It empowers you to elevate your role, get executive buy-in, and deliver a real, measurable impact for your organization. So my goal today for this discussion: I want to give you a systematic way to evaluate your various records and to assign proportionate security controls. We'll start by talking about an overview of the threat that we're facing, and then some common high-value record types that you might be familiar with. Then we'll get into some formal, standardized security risk frameworks, and I'll show you a decision tree that I have developed that can help you decide what is an appropriate security level for a given record type. Then we'll talk about some of the actual specific security controls that you can apply to those records that would be commensurate with the risk that you identified.

Lastly, I want to walk through some examples of how this decision tree works with a few actual record types, and I want you to end up with a way to assign security in a systematic way to achieve defensibility of information the same way we do when we develop a defensible records retention schedule.

[Slide: Latest Data Breaches: "In 2023, 2,300 data breaches impacted over 343 million victims" and "Average cost of a mega-breach in 2024 is $375 million" (sources: Varonis; Statista).]

Okay, so let's get into it. First of all, the threats that we face here: every year it gets substantially worse. And over the year 2023 there were, unfortunately, over 2,300 large data breaches. And it affected over 343 million individuals. How much did it cost, though? We're not talking about peanuts here. One average mega breach for a large corporation came in at over $375 million in damage.

So these things are happening, unfortunately, all the time, constantly. Let's look at some of the most prominent ones from the last few months of this year.

[Slide: Tea app: 72K selfies, drivers' licenses, 1.1 million private messages, precise geolocations; promised info wouldn't be saved; instead, data was hosted publicly for download.]

Some of you may be familiar with the Tea app. This is a social app for sharing dating advice and stories. It basically amounts to an "are we dating the same guy" app, to read the tea. So what happened: they have an authentication process where you submit a selfie and a driver's license. And they of course promised that this would be used only for verification purposes and then destroyed.

But that was not the case. Rather than destroying them immediately, they stored them in a publicly accessible location. Hackers simply had to know what the address was of this storage location to get the data, and they promptly did. They downloaded 72,000 selfies, driver's licenses, and over a million actual messages made by these individuals. Their selfies included the metadata to give you the precise geolocation, so you could see where someone lives, even, and connect that name and address to everything they posted. So this, of course, is, to say the least, a huge problem for the company.

It may well even, it's hard to say what the ultimate consequences will be, but it threatens the company, for sure.

[Slide: Clorox: IT helpdesk outsourced to Cognizant; "Can you please reset my password?"; credentials issued with no authentication; halted manufacturing, weeks of manual order processing; $380 million in damages, $49 million remediation.]

How about another one? Clorox. So Clorox did what many companies typically do: they outsourced some of their IT functions, specifically the help desk, to a third party called Cognizant. And what happened in this case was some unscrupulous hackers called in to the help desk and said, "I seem to have lost my password. Could you please send me a reset?"

But rather than authenticate them or ask for credentials, they just simply issued fresh passwords. And as you might expect, these people burrowed through the various systems, wreaking havoc. It ended up halting manufacturing completely for a period, and then for several weeks they were forced to process all the orders manually. How much damage was really caused by this? Well, according to the lawsuit, which is ongoing, $380 million of damage is being claimed, of which $49 million is remediation. So fairly disastrous for this company as well.

Speaker: Yeah. So these are some potentially high stakes we're dealing with here, Frank. In large companies like Clorox, they might have the resources and the brand resilience to recover from a major data breach like this, but smaller and midsize companies, like the Tea app, for example, don't often have that luxury. For them, a breach could be catastrophic, eroding client trust, damaging reputation, and in many cases it could be the end of the company.

Frank Fazzio: Yeah, I think that's right. For a company with a lot of resources, they can weather the storm potentially, but for a smaller or midsize one, it could be the death knell for the organization itself.

[Slide: Understanding High-Value Records: "Records critical to legal obligations, operational continuity, financial integrity, and historical documentation, whose loss or disclosure threatens the organization."]

Okay, so let's talk about high-value records and what we mean by that, because a lot of you might be familiar with vital records, but I want to talk about protecting really not just vital records but really any record that, because of its situation in terms of your legal obligations, financial or operations, the loss or disclosure of that information could actually threaten the organization. So a little different and a little broader than what you'd consider a vital record: anything that's worthy of protection.

[Slide: High-value record types: Legal (Sarbanes-Oxley filings, patent applications); Operational (just-in-time inventory, emergency response plans); Financial (merger due diligence, customer transaction ledgers); Historical (corporate archives, images, documents, artifacts); Intellectual (R&D logs, trade secrets, prototypes, formulas).]

So a couple of types of character give value to these high-value records. They may have legal value that makes them high value. For example, your patent application: getting that in there right on time and first can make the difference between having the intellectual property or not. Just-in-time inventory: as we saw with Clorox, if that information is scrambled or lost, it can destroy operations. Similarly, emergency response plans, getting back on your feet in the event of a disaster. Financial value can cause it to be high value. For example, if you're doing a merger that involves millions or billions of dollars, the financial calculations from the due diligence could be extremely high value.

How about customer transaction ledgers for financial services, movements of people's money? If that's messed up, your business hinges on that information. It could also just be historical: irreplaceable images, documents, artifacts for the company's history. Or intellectual: the R&D logs or trade secrets, prototypes, formulas that you developed could be extremely valuable.

Speaker: So I'm kind of thinking about this, Frank. So understanding and identifying these records is kind of like the first step forward towards building this security strategy, right? Something that's defensible, something that's resource-aware. I feel like, getting into initiatives and sitting down with stakeholders and whatnot, we oftentimes are talking about records: what is critical, what's vital. And oftentimes I feel like people might think everything is really important, and I think that's fair when you're siloed in your own area. But what does the process really look like for identifying these records that would be categorized as high value? What does that process generally look like? Who's involved in that?

Frank Fazzio: Yeah. I want to cast a wider net than what you'd consider vital records, but it certainly doesn't include every record. So really the test that I like to ask here is, if these were lost or destroyed, could this threaten the organization? That's really the litmus test for what I would consider the high-value record that we want to assign moderate or even high security controls for. So we've seen a few different areas here that are relevant for giving value to records. How about your organization? What character of records are most valuable in your particular company?

Is it more legal that drives value? Is it more operational, more financial?

[Slide: Poll: "What are your organization's most high-value records?" Options: Legal, Operational, Financial, Historical, Intellectual.]

[poll] Let's see what the audience thinks here. I'm going to start a quick poll, and we'll just see what everyone thinks. So how about your organization?

Speaker: Yeah, and we assure that the responses are going to be anonymous. We aren't collecting data here; this is just for collaboration and to try to get everyone involved. But while we're waiting for responses, I was thinking about Zasio's high-value records and came up with maybe source code and system architecture, that kind of thing, on the software side. We're a software company, so that's important. Both the software and consulting sides have client information and employee information that we go to great lengths to retain properly and securely.

We've also got our Versatile database of legal requirements that's very precious to us, so that might be one where, arguably, it's not high, but we have our emotions in it, so we think it is. But last but not least, I think our security and access controls are up there in value too, just because if you don't protect the keys, then everything that you think is high value could be compromised. So that's what I was thinking for Zasio.

Frank Fazzio: Okay, let's have a look at what our poll results are. Looks like operational is at the forefront here, with 39% of the vote. Not surprising, because of course with those operational records, if things get messed up, business comes to a screeching halt. And then obviously we deal in laws and regulations here at Zasio quite a bit, so we understand the legal impact of a particular record and the value that having the law on your side can be, so not surprising that legal comes in second. So we want to have a systematic way of applying security controls through standards. And so the process is, we want to classify records based on their importance for protection.

[Slide: Security Categorization Frameworks: evaluating records to determine their value, risk, and retention/disposal needs. Process: categorize records by importance for protection; use defined criteria, significance, and resource implications; align with business activities and regulatory requirements; assign proportional security protections. Results: consistent, objective evaluation; prioritize resources.]

And based on that, we assign proportionate security protections. And so this gives us a consistent and objective way to look at these records, and in so doing we can also prioritize our scarce resources.

[Slide: Key protection-level security frameworks: NIST FIPS 199 Security Categorization; US National Security Classification Scheme (Executive Order 13526); ISO/IEC 27001:2022. Other sector-specific frameworks: PCI DSS; ISO/IEC 27701:2019 (Privacy Information Management); HIPAA Security Rule; HITRUST CSF; SOC 2.]

So let's look at some of the formal security categorization frameworks that exist. A couple of them are quite common and are used pretty much universally throughout business, both domestically and internationally, such as, for example, the NIST, National Institute of Standards and Technology, FIPS 199 security categorization, commonly used in a wide variety of business contexts. And then there's also the ISO, International Standards Organization, 27001, revision 2022. Another internationally recognized and universally applicable security framework for IT security. For anyone who is a government contractor or working with classified information, there's the National Security Classification Scheme, last updated during the Obama administration, from Executive Order 13526.

And this one will govern any type of confidential, classified, secret or top secret information, so useful for government contractors. There's other sector-specific frameworks too that wouldn't work for everybody, but depending on your industry, narrowly, these could be quite useful and relevant. For example, Payment Card Industry Data Security Standards for credit card issuers. There's the ISO 27701 for privacy information management, for any organization that works closely with personal data. The HIPAA Security Rule, important for anyone managing protected health information, covered health entities.

And then there's the HITRUST CSF and SOC 2, which are both service-based security standards for companies that are managing a lot of customer data to provide services. Actually, Zasio has the SOC 2 certification, because we work with a lot of our clients' data.

Speaker: I'm just kind of thinking about some of our clients, and even Zasio, but it seems to me, for a given organization, several of these might be relevant, though some might be more narrowly relevant for particular categories of industry-specific records, for example. I guess for an organization just generally building out a framework, where's the best place to start? What would be the gold standard, organization-wide, here's where we would start?

Frank Fazzio: Yeah, so I think the best starting point is the broadly and universally applicable standards, such as the NIST or the ISO standard. And actually, I'll get to in a minute why I think that those are the most straightforward approach to classification and categorization of security levels for records. So first of all, the ISO: really it's split into three tiers of security. At the lowest, public, and that's those records that have minimal sensitivity because they're already public, and so unauthorized disclosure is not really going to be that big of a deal. Confidential, next highest level: unauthorized disclosure could cause moderate harm. And then restricted: that's highly sensitive record types where you could cause severe or even catastrophic harm.

So a simple three-tier scheme there. Now let's look at the NIST. Similarly, it's got three levels. So at the low security level, limited adverse effect from loss or disclosure. At a moderate security level, we're having a more serious adverse effect. And then the highest security level, severe or catastrophic adverse effect.

So both of those most common frameworks use a three-level categorization scheme. And I believe that the best approach is to follow those, roughly track those two, and assign one of the three security levels. They call it low, moderate or high, and I call it basic, moderate or high, but really three tiers aligns with those categorization levels and gets the results in a systematic way.

So I want to talk now about this decision tree I was mentioning earlier. So basically my approach here is to interrogate each record type and ask a series of yes-or-no questions to try to understand and drill down on: is the information valuable, and to what extent? And we start with the simplest questions, and then we move on to the more narrow inquiries. So I'll show you this in a graphic here in a second, but I've got the questions here just laid out. At the very first, we'd ask: is the information public? Because if it's already public, well, that's going to end the inquiry right there.

But if it's not public, we'd ask: if it was disclosed or lost or modified, would that pose little to no risk to the organization? In other words, would it be a big deal, or would it be not really a big deal? So if it is no big deal, then again, we end our inquiry. But if it is a big deal, what kind of a big deal is it? So is there financial information involved here?

And then, if yes, is that financial information of the kind that unauthorized loss could cause a significant financial harm, or are we talking about peanuts? Is this a small financial harm? But if it's not financial at all, could it be personal information? Are we having personal information involved with this? And if so, what kind of personal information? Is it the kind where disclosure could harm someone beyond just the basics? Meaning, is it going to be just their name, or is it going to be something like their fingerprints, or their precise geolocation, something sensitive, compromising?

But if we don't have any personal information issues, then we ask: is this subject to a legal retention requirement? Do we have a law that says we have to have this, and if not, we'll suffer consequences? So most common laws with teeth: GDPR, HIPAA, Sarbanes-Oxley, having some substantial penalties for not having the records. But really any recordkeeping law where you don't have the records and you're going to face a penalty. Okay, but if not, then we'd say: is it critical for our business operations? If we didn't have this, would things come to a screeching halt?

And so if yes, then we want to assign a significant level of security for it. But if not, the next question would be: is the record considered vital, needed for disaster recovery or business continuity? And if the answer is still no, then we'd ask: does it contain intellectual property or trade secrets that are worth protecting? And if the answer is still no, then the very last question we would ask would be: does it have long-term historical value or archival value that makes it worth protecting?

[Slide: Data Security Decision Tree flowchart: "Info public?" and "Disclosure/loss poses little risk?" lead to Basic Security; the remaining questions (financial info, personal info, legal retention, critical ops or vital for continuity, IP or trade secrets, long-term historical/archival value) lead to Moderate Security if all are no, while yes answers on significant financial harm, privacy/safety harm beyond basics, severe sanctions for non-compliance, critical ops, IP or archival value lead to High Security.]

And so, okay, it's a lot of text there, but let's see the very same questions in this graphic decision tree, where we start at the top left asking the question: is the information public? And then ask: does the disclosure pose little or no risk? And then we move along with our yes and no determinations until we arrive at one of these three buckets: basic security, moderate security or high security. And you can use this on principle in any record. So now, there we have the decision tree. We're going to come back to that in a little bit.

Speaker: Before we go, that's really handy. I recall you mentioning that you received a question at ARMA InfoCon in Phoenix about whether, we've got this framework now, we can categorize these things, should you be incorporating these security classifications into your records retention schedule? And I just wanted to ask you what your thoughts are on that.

Frank Fazzio: Yeah, so I would say yes, it's a great idea to include these security levels directly on your retention schedule. The only caveat I would... it's really actually important to increase the prominence and visibility of this. However, you have to be careful, though, because once you assign it to a certain record series, then every record in that series, technically, is going to follow that security level. If you choose to put this on something like a file plan or a record inventory, you can get more granular and deal with records on a more narrow basis. But I would say it is important to feature security classifications like this in your documentation and policies and procedures, and the records retention schedule is a great place to do it.

Speaker: Yeah, so that makes sense. So it kind of operates like the retention period, in a way, where you've got one record that might be driving it slightly higher and then all the other records have to follow it. And in the same way, the security classification would work in a similar way, where if you've got one record that's high, then if you're doing it on the retention schedule, every record is going to be displayed as high, which might not be the best.

Frank Fazzio: Exactly. Yeah, so you just have to be careful about how you do it.

Okay, so we'll come back to that in a minute, but what I'll talk about now is some of the actual security capabilities that you can use. So these are the countermeasures that you might apply based on the security level that you decided on for a particular record. So we'll talk about access controls, system hardening, data loss prevention, encryption, electronic vaults, and disaster recovery. So let's dive in on these. The first, and the front line, is access controls: stopping people from seeing or being able to read or edit or modify a record that they shouldn't have to.

So at the basic level, make things read-only, and then have some minimal restrictions so that not everybody can see everything. At a moderate level, you might use multi-factor authentication before letting someone in, and then have role-based access controls that get reviewed regularly. At the highest level, though, you'd probably go beyond just role-based access, and you'd say no, we're going to shrink things down to the least of what's necessary for someone to do their job: strict least privilege principle. And then for authentication, more than just two-factor authentication, you may wish to do biometric multi-factor authentication with fingerprints or face geometry. And then you'd want to monitor continuously and be able to revoke access in real time if a problem was detected.

Next, secure system hardening. This is basically shrinking down the surface area and ways for bad actors to enter your systems, removing the vulnerabilities and giving them fewer areas of attack. So at the basic level, these are familiar to a lot of people: you'll have firewalls, and you'll remove unnecessary software, keep things patched and updated, and authenticate any changes to the system. Then at the moderate level, you'd use secure configurations, like shutting down different background processes that aren't really necessary and can be vulnerabilities, and then intrusion detection, so getting a notification when there's some unauthorized access attempt. And then at the very highest level, you might have segmented networks that are all separated from one another and don't trust each other, that zero trust architecture, where they have to authenticate with each other before exchanging data, and then an intrusion prevention system that can actually not just detect when there's an attempt, but actually shut things down and wall things off to limit the damage in real time if there is an intrusion.

And then the next big one: data loss prevention. This is trying to make sure that even if you get an attack past the front lines, they can't make off with the booty. They can't get out with the data or records. So at the very basic level for data loss prevention, you'd be logging the access or the change actions. Moderate level, you'd use blocking of some kind in basic data loss prevention, like stopping USB transfers or email, unable to email things out, and then monitoring the access or change actions so you can detect if someone makes an attempt to make off with something. Highest level, though, you do more comprehensive data loss prevention: stopping all cloud uploads, stopping all external drives, and then not just monitoring change actions, but real time, with automated responses to block those extraction opportunities and let you deal with it immediately.

Rick Surber: Yeah, my experience with the real-time alerts is that they work really well. Zasio doesn't allow flash drives, and so when I got this Bluetooth headset that I'm wearing right now, I plugged in my USB dongle and immediately got a message from our security lead asking me if I plugged something new into my computer. And I was like, whoa. It turns out that this particular headset has some internal memory, and it flagged as a flash drive. So they were able to [inaudible]. What's that?

Speaker: I said that would have been Warren, right?

Rick Surber: That was Warren, yes. Like, "Yeah, Rick, what'd you plug into your computer?" I'm like, whoa. Yeah, it was impressive how immediate the response was. It's pretty, pretty crazy.

Frank Fazzio: Yeah, we've got things buttoned up pretty tight here at Zasio, so my hat's off to him.

[Slide: Encryption (protect against unauthorized access). Basic: encryption in transit (e.g., TLS 1.2 for network communications). Moderate: encryption at rest using symmetric AES-256; secure key storage and rotation. High: end-to-end encryption (E2EE) for data in transit and at rest; asymmetric public key / private key RSA encryption; Hardware Security Modules (HSMs) for key generation/storage/rotation.]

Okay, next big one: encryption. And this is actually the technology that powers Bitcoin. Needless to say, it's very effective. The idea is, if things are already scrambled in encrypted text, then it makes it that much harder for a bad actor to do anything with them. So at a basic level, encrypting information in transit.

So most of the internet works that way, TLS 1.2. At the moderate level, you'd have encryption of data at rest, using a 256-bit level of encryption, considered pretty moderate security there. And you'd be careful about the encryption keys, which are needed to decrypt data. You'd want to have those stored securely and rotate them from time to time. And then at the very highest level, you'd have end-to-end encryption, so that the data is always encrypted, both in transit and at rest, so very little opportunity for anyone to get hold of the plain, unencrypted text.

And then there's more complex and secure key architectures. The asymmetric public key, private key scheme is one. This is actually how Bitcoin works, whereas you need both keys in order to really read the information. And so that's just one extra level of complexity and security. And then you can use hardware modules for storing encryption keys, an actual token or other device, and then it can help you to generate and store and even rotate the security keys you're using.

Speaker: I think it's really kind of insightful and interesting, as you go through this, Frank, you see that security really isn't just about one control. It's more a layered strategy, and things like encryption, I know not every organization is using that level of security or protection. It's really maybe not necessary for the types of records they have. But I guess, from your perspective, and what you've learned, and what we've kind of learned even talking with Warren, what do you think is the most fundamental or most critical thing any organization can do out of all of these strategies we've talked about so far?

Frank Fazzio: Yeah. So I'd say probably, of the ones we talked about so far, access controls are the most immediate one, where you can gain a wide range of protection simply by segmenting different access levels for different personnel in your organization, and establishing those, the prevention of letting everyone access everything. That's a huge step forward right from the get-go. So I would say that's probably the front line, your very first and easiest low-hanging fruit of implementing some security capabilities.

Okay, a few more here. Let's talk about electronic vaults. So this is basically setting up a dedicated repository with extra security controls. That's really your location for storing high-value records. At the basic level, you'd have a standard repository that is designated for these high-value records. Moderate, you'd use something like a secure document management system that would include features like version control for each record that it contains and audit trails of any changes or transformations.

And then at the highest level, a true electronic vault that is going to be encrypted by its nature, and usually geographically redundant in the cloud, with tamper-proof logging for all the access or modifications. That really gets you at the highest security level. And that's really mostly useful, it's best used, in situations where documents need to change hands and you need to be able to prove the custody of high-value documents. Things like mortgages and loans benefit a lot from being kept in electronic vaults.

Speaker: I don't typically think of an electronic records management system, or an ERMS, as a vault, but I see some similar attributes here. Where would you place an ERMS on this kind of high, moderate, basic, Frank?

Frank Fazzio: So I think an ERMS, in the basic way, it is document management, and in a secure format, and it will have audit trails of transformations that have happened, and you'll be able to see different versions of a particular document. So I would say an ERMS like Zasio's, for example, would fall under the moderate security level on this.

Speaker: It's interesting.

Frank Fazzio: Yeah. Okay, so lastly, we've got disaster recovery. And so this is making sure that even if everything else fails, you'll be able to at least recover your information. So at the basic level, you would do routine backups, and at least having restoration be possible. At the moderate level, you're doing your backups more regularly, either incrementally daily or have a full backup every week, and keep those backups in an off-site location, and then get actually standards-based about how you measure the backup effectiveness. So recovery time objective: how long you are allowed to have the system down before it can be restored, in an hour or two, for example, or a day, or 15 minutes. And then recovery point objectives: how far back in time do you need to go? Do you need to be able to go back to yesterday, or a week ago, or how far back do you have to go?

At the very highest level, you'd do all that, but you'd also have a recovery plan that you would test, and you would do fire drills and train your staff on how to get things going.

Rick Surber: And even the backup here has some nuance to it. I remember studying for the CRM, the technology part of it, the 3-2-1 backup strategy, where you have three copies of your data, using two different storage media, maybe one local server, one in the cloud, and then you have one off-site and air-gapped. So you can even go further with how you're backing up your data, right?

Frank Fazzio: Yeah, that's pretty robust.

Okay, so let's get back to that data security decision tree. I want to run through a few examples now. And I'll ask Rick and Jen to help me through it. So let's actually see this decision tree in action here and decide what security level we should assign to these records. So first example here, we're going to deal with BusyWork LLC.

These guys are a professional services company, and they specialize in repetitive and mundane tasks. And so three times a week, the project manager convenes a departmental meeting. It's about collaboration, of course, but as you might imagine, the meeting could have been an email. And so during each meeting, every employee goes through their deliverables, upcoming deadlines, and then summary notes are taken and distributed. So what do we do? I'll ask you to help me on this one, Rick. Let's work through the analysis on these departmental meetings, the minutes and the agendas.

First of all, is this information public? That's right, it's not public. It is an internal meeting, so it's not out there. But then let's ask the question next: if it were to get out there, and this meeting information got out, would the disclosure pose little risk, or would it be a significant risk to the organization?

Rick Surber: Probably pretty little risk. Not sensitive information. Whether it's identifiable is the question, but probably very little risk.

Frank Fazzio: Yeah, I would agree with you there. So this is not something that we want to be distributed, but then again, this is just status updates and deliverables. It's probably not going to be catastrophic. So I think we can put that one to basic security. Answer yes, it poses little risk, and we arrive at basic security. Okay, that was pretty easy. Next one.

Another example. So we've got ClosedAI. They're a new company. They developed artificial general intelligence, or AGI, and they're calling it BratGPT. All right. So the source code: they've been working on this for years, and they've been spending millions of dollars on it, and really, this is the future. So they have a competitor, though, of course, ScryNet, and these guys are also hard at work on their own rival large language model, hoping to achieve AGI.

So Jen, I'll ask you to help me with this one. First of all, is this information public?

Jennifer Chadband: I'd say no.

Frank Fazzio: No, it's kept internal, the source code. And then does the disclosure here pose little risk to the company?

Jennifer Chadband: I would say no. I think it's high stakes. High risk.

Frank Fazzio: Right. So we've got some important information here, exactly. So what exactly is the character of this? So first we ask: does it contain financial information?

Jennifer Chadband: No.

Frank Fazzio: Right, it's computer code. So no, moving on. Does it contain personal information?

Jennifer Chadband: I would say no.

Frank Fazzio: Yeah, probably not. And then next. So no. Next question: is it subject to legal retention?

Jennifer Chadband: This is debatable. Yeah, that's a little bit debatable, but generally, I would say probably not.

Frank Fazzio: Yeah. AI regulation is developing, and the European Union is hard at work on this, but as of now, I wouldn't say that there's any specific legal retention requirement for this source code. Okay, but moving on: does it support critical operations, or is it vital to business continuity?

Jennifer Chadband: Yep. Working at a software company, I can confidently say that's a yes.

Frank Fazzio: Yep, exactly. Extremely important, and they've been working on this for a long time. This is critical, really, for operations moving forward. So we answer yes to this question, and then we follow our dotted line down to high security, following the check mark. So yeah, we want to assign high security to that source code.

All right, very good. Another example, Rick. So we have Spam 24/7. They're an online retailer who specialize in canned meat products. They maintain a subscriber program where customers can provide their email address, and they can receive multiple emails every day about new products, rewards and promotions. And then the list has their emails and also their birthday, so that of course you can get your can of free Spam on your birthday.

So what shall we do with this? First of all, is this information public?

Rick Surber: No.

Frank Fazzio: No, this customer mailing list is not public. It's internal. Does the disclosure pose little risk?

Rick Surber: Arguably, no. There's some risk there.

Frank Fazzio: Right. They use this; the marketing is not their whole business, but it's an important part of their business. And so it would be a risk if this was lost or destroyed. Next. Okay, so what kind of harm would this be? Does it contain financial information?

Rick Surber: No financial information.

Frank Fazzio: Nope, correct, no financial information. What about personal information?

Rick Surber: Yes, there is some personal information there. We've got names, birth dates, email addresses. So whether it's identifiable, I don't know, but there's personal information there.

Frank Fazzio: Right, it is personal information, exactly. So that's a yes, and now we drop down to the question below: is it the kind of personal information that would harm your safety beyond the basics? And I would say this is a tough one; it's debatable.

Rick Surber: I would say no. Email addresses, birthdays, these are still things that are fairly common out there. It's not sensitive health information or something like that, so I would say no to that one.

Frank Fazzio: Yeah, I think that's right. If it was something biometric, if it was your precise geolocation, I would say yeah, this starts to get more serious. But just simply having the name and email address and birthday, that's not really... That's bad, certainly, but it's not the worst. So, okay, so we'd say no, it's not the personal information beyond the basics. And then, is it subject to any legal retention?

Rick Surber: Arguably, again, probably no. There might be general privacy requirements that might be relevant to it. Maybe some catch-alls, but not specifically.

Frank Fazzio: Right. Yeah, not specifically required to retain it, although you are required under privacy laws to make sure it's not misused. But then, does it support critical operations, or is it vital for business continuity?

Rick Surber: I would again say no. This is really part of their marketing, to give these free cans of Spam, which is nice, but they could continue to exist as a company if this list was compromised.

Frank Fazzio: That's right. This is very important, but they could, if they had to, start over with a new subscriber list. So it wouldn't be a death knell for the company, I would say. And then, okay, so no. And then next question: does it contain intellectual property or trade secrets?

Rick Surber: Nope.

Frank Fazzio: No, not really. It's just a mailing list. And last question, then: does it have archival historical value for the history of the company?

Rick Surber: Nope.

Frank Fazzio: I would also say no. All right, so because we've got a no on each of those, we're going to go down the moderate security lane for this. We want to assign robust security for this, but it is not exactly the crown jewels of the company, where we would spend the most amount of money and resources on protecting it.

[Slide: Deploying Resources chart: security (vertical axis) against investment (horizontal axis); curves for basic, moderate and high security rise sharply at first and then flatten, with high security gaining the most.]

Okay, that was great. Now, on that point, though, I want to talk a little bit about deploying your resources effectively, because part of the reason that we do this is we don't have unlimited money, we don't have unlimited resources. We have to deploy them in an efficient way, proportionally, to the different types of records that we have in an organization. And that's part of the reason why we don't want to assign everything high security. We can't do that; it's not practical or feasible. So we have to make these tough decisions about what controls we'll assign to which type of record, and it depends on the resources available to us, also the context of the particular record type: does encryption make sense for it, does an electronic vault make sense for it?

So in this chart, I want to talk about how you really do get diminishing returns the more that you spend on it. When you go from no security at all to a higher level of security spending investment, you get a sharp benefit right off the bat, and that benefit is sharpest for records that need high security. So you immediately get a benefit. But be careful, though, because the more you spend, it eventually flattens off, and you stop really getting much benefit. You get diminishing returns as you go along.

So be careful. You don't want to be spending an infinite amount here. Now, we're talking about how much security you achieve based on how much you invest. But if we talk for a moment about the value add, how much does this actually better the organization, by investment in security? I think the situation looks even different. So of course you add value by assigning security when you started off with none at all, but at a certain point you're spending enough, and you're creating enough barriers to access, more red tape. You have things buttoned down so much that it actually hinders the accessibility of the information and the ability for people to do their jobs.

So at a certain point, not only are you spending a lot, you're also diminishing the value of the information with so much security. And I would argue that once you get beyond a certain, sort of the peak of value add, you're actually destroying value, the more levels of security that you layer on there. So you have to be careful here. You want to hit the sweet spot: just enough, and not too much.

[Slide: Spending % of IT budget (on security) by industry: Retail 6.0%, Manufacturing 6.1%, Financial Services 9.6%, Consumer Goods & Services 9.7%, Business Services 13.2%, Healthcare 13.3%, Technology 13.3% (source: https://www.techmagic.co/blog/cybersecurity-budget).]

So yeah, that's really critical. And then let's look at how much is a typical amount to spend here. It really depends on your industry. I'd say that some of the industries, like manufacturing or retail, that don't have quite as much volume of information, and it's not quite as sensitive, they might not spend as much. So somewhere around 6% of their IT budget might get deployed there. Whereas something that's more sensitive, like healthcare or technology, where they either have much more sensitive, regulated or higher volumes of information, they need to spend more on security. So you see something around 13% there. So somewhere in that range is probably going to be the sweet spot of how much should be spent there. So, anyway.

[Slide: Questions? Get In Touch: 401 W Front St, Suite 305, Boise, ID 83702; Jennifer.Chadband@zasio.com, Richard.Surber@zasio.com, Frank.Fazzio@zasio.com; +1 (800) 513-1000 x802.]

Yeah, now, in conclusion, we'll open things up for questions here in a moment. I just want to leave you with, really, getting through the process of classifying information with a standards-based way to give you security controls. It really unlocks tangible value in the organization as a records manager, and it elevates your visibility to being a frontline strategist at the crossroads of IT, legal and business. So yeah, and really this positions you as a guardian of enterprise knowledge and makes sure that you're not only relevant, but pivotal in navigating the digital landscape for your organization. So with that, I think we'll have a few questions now. And thank you for your kind attention. If we don't get to your question, I would invite you to email us or give us a phone call, and we'll make sure to get back to you.

Speaker: And I've got one. I think this is maybe towards Jerry. Jerry, can you get that PDF of the flowchart up, so that people can print it off and use it? It seems like a pretty handy thing for people just to have as a reference point, to be able to print that page off and use it when they need it.

Jerry Manter: Yeah, we'll be able to share that in our follow-up communications, probably tomorrow, actually.

Speaker: Great.

Speaker: Okay, did we have any live questions, Jerry?

Jerry Manter: Yeah. [audience question] How do you recommend organizations handle records that fall into multiple value categories, such as legal and historical, when assigning protection levels?

Frank Fazzio: Yeah, so I can answer that. I'd say, if you've got multiple different record types, and they straddle, you've got some where it's clearly high security, others where it's moderate or even low security, the safest approach, if you have to assign a particular security control, go with the security control that is at the highest level for the records that are being contained in a certain repository or record series. So if you have to choose, I'd say err on the side of greater protection. You don't want to leave any particular record underprotected. So if things are right on the margin, or you have to choose between two options in a gray area, you're better off moving to applying the most privileged, highest level of security for any of the records that are in front of you.

That would be my recommendation.

Speaker: There's a bit of a risk analysis that goes with that too, though, right?

Frank Fazzio: Well, I'd say that's right. You have to take it with a measure of reasonability here. And again, if you've got just one, let's say 99% of something really belongs with moderate security, and just one item that you decided should be high security, it might...

Speaker: Maybe it's questionably high security. That even makes it even more persuasive to maybe go with moderate.

Frank Fazzio: Exactly. So you've got to use common sense, you've got to use your head, and you can't be too formalistic and rigid with how you do this.

Jerry Manter: [audience question] Okay, our next question: among the security measures you discussed, which do you consider most critical for protecting records in a cloud-based environment?

Frank Fazzio: So that's a good one. I'd say, of all the different security measures we talked about, I'd say if you're going to get started, access controls are the most effective. But if you're talking about cloud data, I would say encryption is probably the first and most effective security measure you can use, simply because of the amount that it costs to implement it versus the amount of benefit that you get by having the data be encrypted and unreadable. It's a huge bang for your buck. And so I would say that for cloud data, it's very easy to access it because it's in the cloud, but if you don't have the ability to get it in unencrypted form, you can't do much with it. So that's why I would pick encryption as probably one of the most effective and efficient-for-your-dollar security measures for something like a cloud-based environment.

Jerry Manter: [audience question] Okay, our next question. This is for Rick, actually. Can you describe the 3-2-1 backup strategy again, specifically the one?

Rick Surber: Oh yeah. So the 3-2-1 backup strategy is you have three copies of your data. You use two different storage media, so maybe one is like a local server, and one could be in the cloud, something like that. And then the one is, it's off-site, and it's offline, so it's not interconnected to the rest of it. Some people go as far as having it be air-gapped. And so, yeah, that's the one.

Speaker: Is that called cold storage sometimes, right? Cold storage. Hot versus cold. Yep.

Speaker: Yeah. And then I don't see any other questions. Do you have anything else, Jerry?

Jerry Manter: [audience question] I do have one more pre-submitted one that we can go over. How do you suggest records managers navigate conflicts between departmental priorities and enterprise-wide information governance standards?

Frank Fazzio: Well, yeah, that's kind of a tricky one. I'd say, anytime you're navigating disagreements between departments, it's necessary to get the important stakeholders at the table and make sure to leverage their expertise, give them their chance to be heard, so that you reach a consensus. It's a political exercise by its nature, dealing with different people in different departments. So by paying respect to what's important to every department, you can arrive at a consensus that works. And you don't want to ignore the important considerations of any business function or department.

Jennifer Chadband: Oh, I was just going to say, that might kind of fall within the decision-making or purview of steering committees, right? Some of that final decision-making.

Speaker: Yeah, and I was going to say, I think as records managers, we often find ourselves as mediators. It's just part of our role, and even as an extension, as consultants, we are often mediating these things that come up, and I think that's important.

Speaker: All right, so it sounds like we are at time. I just wanted to let everyone know that Boise ARMA's sponsored charity this year is the Idaho Food Bank. We've got a link to donate on boisearma.org. And we will have a fund drive opening up soon, where we will match up to $300 in donations for the Idaho food drive. So yeah, if you can, stop by the Boise ARMA website and donate.

Thanks, everybody.

Speaker: Great job, Frank.

Speaker: Have a great rest of your day. I appreciate it.

Speaker: Thanks, everyone. Take care.

Speaker: Thanks. Bye.