CISSP Cyber Training Podcast - CISSP Training Program

CCT 318: APIs To End Of Life (EOL) and End of Service (EOS) - CISSP Domain 2.5

• Shon Gerber, vCISO, CISSP, Cybersecurity Consultant and Entrepreneur • Season 4 • Episode 318

Share episode

Send us a text

Check us out at:  https://www.cisspcybertraining.com/

Get access to 360 FREE CISSP Questions:  https://www.cisspcybertraining.com/offers/dzHKVcDB/checkout

Get access to my FREE CISSP Self-Study Essentials Videos:  https://www.cisspcybertraining.com/offers/KzBKKouv

Podcast Link(s): https://www.securityweek.com/cyber-insights-2026-api-security/

Agentic AI doesn’t just call your APIs; it creates them, connects them, and expands your attack surface faster than most teams can map it. We open with a frank look at autonomous agents, the Model Context Protocol (MCP), and why weak authentication, misconfigurations, and shadow APIs are still the easiest doors to pry open. Then we get tactical: continuous discovery, behavioral analytics, context-driven access, and the governance you need to monitor what AI spins up and revoke what shouldn’t exist.

From there, we shift to the CISSP core: end of life, end of support, and the asset retention practices that keep you compliant and resilient. We define the terms, share real-world pitfalls, and outline practical sunsetting plans that include data migration, isolation when necessary, and rock-solid disposal. Documentation is the quiet hero—config backups, change logs, destruction certificates, and retention schedules shaped with legal and compliance. Over-retention inflates breach impact and cost; under-retention invites fines and operational gaps. We walk through legal holds, immutable backups, and the cost conversations that stop data hoarding.

By the end, you’ll have a clear blueprint: integrate lifecycle management into procurement, track vendor notices, consider extended or third-party support when needed, and use compensating controls for what must linger. Train your teams, audit your process, and map ownership so you can prove what you keep, why you keep it, and when you delete it. If you’re ready to tighten API security and retire legacy systems without breaking the business, this one’s for you. Subscribe, share with your team, and leave a quick review to help others find the show. What legacy system will you decommission first?

Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

Join now and start your journey toward CISSP mastery today!

SPEAKER_01:

Good morning everybody. It's Sean Gerber with CISSP Cyber Trading and hope you all are having a beautifully blessed day today. Today is CISSP Training Monday, and we are going to be going over specific training related to domain two. This is 2.5, ensuring appropriate asset retention. Yes, you want to have asset retention. You want to make sure that you have a good plan related to all the assets within your organization. And this is going to be a great podcast that's going to go over all of that for you. But before we do, I had a quick article I wanted to share with you all related to AI. Okay, so as you all know, APIs are something that I truly enjoy and think they're great. And other things, APIs can be a challenge. They're the connective tissue to make the internet work. And we know this, and we know that they can be very productive and very helpful for an organization. But from a security standpoint, they can also be very challenging and very disruptive if you do not have good practices in place. Now, getting the API protections in place from the past has been a bit of a challenge in of itself, right? I've seen it time and again where you have folks that are utilizing API connections and they really truly don't know what they're doing. They just know that they connect it and it works. And so that has caused some level of drama in many companies and many organizations. Well, now we're just going to add to that a little bit more and add the agentic piece of this where you now are adding AI into it. So agentic AI is the main driving force of this potential risk in 26. And what they're doing is they're utilizing autonomous AI agents to increase the number and dynamism. That's a big$10 word. Basically make them dynamic of APIs, utilizing the capabilities between them so that you have an ability to utilize it in a more autonomous or authentic mode. This creates a larger and much more volatile attack surface that we were actually protecting before, because now you're going to have agentic AI making and basically shutting down these types of connections. So having an understanding of where all the endpoints on all the APIs exist is going to be a challenge. I had a whole big problem dealing with employees that were setting up APIs, let alone letting the AI do it itself. So it's going to be quite challenging. I mean, it truly will be. So it'll be interesting to see what they come up with to help off deal with some of these aspects that are going to be happening. But one of the things that are we see potentially coming, or we see what Security Week is seeing, and I can also kind of corroborate that, is that weak authentication and misconfigurations will remain the top exploitation vectors. And we see this in almost everything out there. People want an easy button, throw it in place, let it run, and then it'll figure itself out. Unfortunately, these misconfigurations, because people just didn't configure them the right way at the beginning, are going to exacerbate the problem and make it much worse. Shadow and undocumented APIs continue to proliferate, and that is something that I dealt with. And you as a security manager in your organization will deal with that as well. And now if you integrate it with agentic, you're going to have even potentially more challenges as well with that. And then attackers are using AI for automated enumeration, fuzzing, and credential stuffing. So some of the big risk areas they see at this coming is the AI-specific protocols, and it's called MCP. This is model context protocol. And what MCP is, just kind of a real quick rough, because I didn't really even know what it was. So I started kind of figuring this out a little bit on my own, looking it up and Googling it, figuring out how does this all kind of connect together. Well, what it really is, is it's a standardization protocol that allows AI models to basically utilize their autonomous agents to securely interact with tools such as APIs and other data sources. And what it comes down to is just reading through this, it is, we all know that tools can be very static. They can be very, I don't know how to say the right word, but they're they're very singular in their focus. This is going to basically create the little buffer that's going to connect your AI, in this case, agentic, with the tool. It's that connective piece that is going to be a big factor in this, and that is the model contextual protocol, or otherwise known as MCP. So it's designed for autonomous activity and non-deterministic AI workflows. So it's designed to basically interact with you, that connective sinew that's going to go between those. So there's a lot of issues that can run into this, right? So we've got over permission tools now, uh, and you have AI working with overpermission tools. Greater challenges of visibility and attribution, that's a big factor. And auditability. This is going to really be interesting, going to spin up the audit folks on how to actually deal with this. I didn't even think about that either as I was digging into this. It's going to make things extremely challenging. So the bottom line is MCP is really the big factor that's going to drive a lot of change in this space. And to be the nanny to say, well, don't do it, just don't use it. Well, I don't think that that is something you can actually say. You're going to end up using this, and business leaders are going to require you or they're going to want this technology be deployed within their organizations. So you as a security professional is going to have to figure out how do you deal with this specifically? And how are you going to put things in place to make this happen? So, OAuth, third-party integrations, they're propagating through weak sources and unclear revocation policy, all of those things are a big factor. So when it comes right down to it, you must evolve API security. And this will require continuous discovery, behavioral analytics, and contextual driven access controls. You're going to have to pay attention to what's going on. There's no way around it. And so I would highly recommend that if you have APIs within your environment, you work very diligently to have a good API tool that you're monitoring, that you're pushing everything through this cape, this gateway. And then now when the Gentic kind of comes in, I would also consider if you're going to roll in Agentic into your API framework, look at ways that you can then monitor how AgenTic is going to be creating these API connections. And then you're going to have to really get smart on it. And I'll be telling you, this is the problem, is technology is moving so fast, so few people, and I would say probably very, very, very few people have a firm grasp on all of this capability. So unfortunately, business owners have super limited visibility. They just want it to work. You have visibility and you want it to work, but you also want it to be secure. So it's important that you as a professional kind of start getting smart on this. And I'm saying that to you all, but I'm also pointing fingers back at myself. An area that I need to get smarter on as well, because it's only going to get more and more in depth as time goes on, especially in 2026. Okay, so again, this is a great article. I would recommend you go and then kind of dig into it. It's a great way to kind of cut your teeth on learning about API security, as well as then go and start Googling it or even chat GPTing some of the different things that are inside this to kind of peel back and understand the overall aspects for your organization as well. So a lot of great stuff could come out of API connections, no doubt about it. But it also, just like a hammer, can be used for good and it can be used for evil. So go take it out, check it out, see what go see what you think of it. Okay, so let's get into what we're going to talk about. But before we do, I had a quick shout out for CISSP Cyber Training. Head on over to CISSP Cyber Training and look at all the free stuff that's there and available to you at CISSP Cyber Training. A lot of great content available to you to get ready for the CISSP exam. But on top of that, again, we're here to help teach you what you need to know to be successful in the cybersecurity space. The ultimate goal of this is not to help you pass just pass the test and move on. It's to give you the information, the knowledge you have to pass the test well, but at the same time give you the foundational aspects so that when you go into whatever role you're going to be going into, you are better prepared for it. Also just wanted to set the stage where I get lots of students pinging me on the side saying, hey, what about this from my career? How do I do this for this job upcoming job promotion? Check it out at CISSP Cyber Training. I've got products and plans that can help you with that. So again, go check it out, CISSP Cybertraining.com. Okay, so this is domain two, two dot five. Ensure appropriate asset retention, basically end of life and end of support. So this is a big factor when you're relating to any sort of device that's in your organization. And it comes down to physical devices as well as the different microservices and different types of services that are in place from a virtual standpoint. You need to keep track of all of your assets because, yeah, granted, a virtual asset can be upgraded. The software code can be upgraded, and you can continue those things for quite some time. However, the problem is also what happens when these devices are really no longer necessary for what task you had planned for. How do you dispose of them? And do you have a process to deal with disposing of these assets? So end of life. Definition of end of life is a stage when a product is no longer produced, sold, or supported by the vendor, indicating that it should be phased out of use, right? Makes sense. If something is end of life, you need to get rid of it. Shut it down, get rid of it, send it someplace else, send it to the old person's home. That actually kind of gets close to home because I'm getting closer and closer to the old person's home. But the there should be an end-of-life process. This comes down to where you have asset identification and you must maintain an updated list of assets and their life cycle status. Now, again, I mentioned before, this includes your virtual type activities, your virtual machines, your microservices, all of these types of activities, and any asset that you have that's processing your data, you need to keep an updated list of those. This can get quite challenging, right? Especially as you have individuals that are working in this space. As we get more in the development world, it's gone from a more of a physical device to an actual virtual device. But this is an important part. You need to understand your overall assets. You need to have a sunsetting plan, develop a structured plan to decommission these assets. This would include data migration and continuity plans. So, an example is I had a facility that was still running on Windows 95.

SPEAKER_00:

And you would go, gas, yes, that's true.

SPEAKER_01:

Windows 95, what is that? That is not really pretty new. It's pretty old, right? So the point of it was is they had systems that had cannibalized that they kept around to keep running this Windows 95 system. Now, is that smart use of their technology in time? No, but at the same time, is when you're a business and your margins are tight, you do you continue just kind of limping along with the Windows 95 device, or do you go out and spend$22.3 million on some other thing? Yeah, it's a hard hard thing to decide on, right? So the point comes down to you need to have a good sunsetting plan and everybody needs to be aware of it. You have a data retention and during your end of life. So what are you gonna do with the data? So you need to export it and migrate it from these assets to ensure that it's properly transferred to new systems or it's archived securely. So you gotta have a plan. You can't just go, okay, well, we don't need it anymore, shut it down. Then you'll hear lots of people screaming and gnashing of teeth, and then there will be pitchforks and torches, and you will be the person they will be coming to put and set on fire. Retention policies post-end of life, you need to determine how long the data associated with these end-of-life assets must be retained based on your organizational and regulatory requirements. Now, that this kind of really depends upon what that asset might be. If it's a device that's storing personal information and you want to keep that, that can have regulatory challenges. In most cases, if it's an old end-of-life system, you probably can decommission it pretty quickly. Uh but it mainly comes down to what is your organizational requirements around it. In most cases, they're going to want to have the data removed from that system and migrated someplace else. Now, security considerations and asset disposable, so disposable. Yeah, it is disposable. Disposal. So security considerations you want to think about is end of life systems are vulnerable if they're kept in production, right? And uh Windows 95, that is extremely vulnerable if it's kept in production. Now, some will argue that, you know, it's so old that no one can do anything with it. Yeah, I don't think you want to take the chance on that one. Because the simple fact of it is is okay, let's just say that's let's use that hypothesis for an example. And you leave this Windows 95 system out there and running. Well, what happens if you get hacked? All right, you get hacked, and let's just say it's not even part of the hack that occurred. But because you have asset inventory and you now supply this to the folks that are gonna be trying this court, you in a court of law to determine were you negligent, and they see the fact that you have a Windows 95 device still sitting on your network, they're gonna go, uh, dude, dudette, you are not doing a good job of protecting your people's information. So therefore, you're guilty. And so I mean it. I I know as crazy as this sounds, it could very easily happen to you. So I would highly recommend, highly recommend that if you have all those old systems, get rid of them. Isolation techniques, you can implement network segmentation and strict access controls for these you these end-of-life devices. I would I have seen people milk this out for years and years because of this. They put them in a different network, they have strict access controls on getting access to them, and so therefore, it is in an isolated bubble. That being said, it's still potentially vulnerable and it opens you up to risk. So you've got to decide is that something that must happen. I would highly recommend that if you're going to do this, uh, that you have a sunsetting plan set up specifically for these isolated networks, that you're gonna be migrating off of them as soon as you possibly can, and then you have a plan to do such a thing. Now, asset disposal, there's secure disposal methods. This ensures that all the data on these end-of-life systems are securely wiped or destroyed. And there's plans and you should have documentation related to that. You need to keep the detailed records of the destruction process to demonstrate compliance and avoid potential data leakage and breaches. So, one thing is worst case you can see is that someone has a bunch of old plattered hard drives that are sitting around in an office somewhere and they get confiscated for whatever reason, someone walks home with them and they have all kinds of data on them. That would be a problem. So, therefore, you need to have detailed records around this. If somebody is, you say you bring a third party in that shreds these things for you, that's great, but you need to make sure you keep the documentation on the devices that they shredded. Okay, I again I can't tell this enough. In today's litigious world, people will come after you if you do not have the proper things. They're gonna come after you no matter what. But at least if you have the topic documentation and you have done the right things, you're the the odds of you getting into a position where you can't where you're liable, it goes down substantially. It doesn't mean it goes away, but it goes down substantially because you have done the right things and you have it documented. Definition of end of support, this is a point where the the vendor or manufacturer will no longer provide updates, patches, or technical assistance for software or hardware products. So that's the end of support. So they were not going to have it. Windows 95 will not give you anything that you to make your product work anymore. Or they used to, they still do where they will extend it a bit just so that you can pay them more money, but at even that comes to an end at some point. Now, there's security risks obviously because of these end of support systems become high risk targets and because they no longer receive any sort of security updates, leaving them open to any level of exploitation. Now, there's compliance violations that also go along with this, is that if you, depending upon which organization you are with and what kind of regulatory requirements you have, you have compliance requirements to get this done and remediated as quickly as possible. So you need to have a good transition plan. And this would be one of the key factors is having inventory, have a good comprehensive inventory to identify the assets that are approaching end of support. Just like end of life, you need to have that in place as well. And then you have a need to have an upgrade path designed for these systems. This will may entail up new software, it could entail new hardware. You have to decide what that's going to be for you and your company. Now, a risk assessment can occur to evaluate the risks associated with running these assets past end of support, and then you can implement some sort of compensating controls if required. Now, that is going to be a discussion that you will need to have with your business units as well. This is not something you would do in a vacuum. So this could be a CI, a great CISSP question that you see end of support. You're going to decommission these systems. What would be the best response that you should do? Uh yes, you should reach out to the business units and ask their opinion on what happens when I get rid of these systems. That would be a manager thinking about what should you do with end of support. So risk doing a risk assessment and then reaching out to the business units is a critical step in any of these activities. Support extensions, you can extended support contracts, and this would uh obtain limited vendor support past the initial end of service date for critical systems. And then, as well as third-party patches, these include patches or updates provided by third-party vendors when primary support ends. So I've dealt with this in the manufacturing space. There were times when they would provide a patch in a limited, uh kind of a limited patch because they're waiting for an upgrade, but they would provide this on specific PLCs because they knew they were vulnerable. So again, it comes down to what is your specific situation, but keep open to any and all options. So asset retention strategies. So the purpose of retaining assets is one, business continuity. Ensure that the important data that remains available to support your business operations. You want to make sure that you have that in the event that there would be an issue. Regulatory compliance, retaining data for specific durations to comply with legal and regulatory requirements is a must. So there will be you'll have to keep this information for a period of time. And then also historical or legal need, which kind of goes hand in hand with the regulatory compliance piece of this. And this is for auditing, litigation, or historical reference. So there's a reason you're gonna want to keep these assets within your company. Now, the retention periods, these are a lot of these are policy-based. So you will establish a policy or your organization will based on the data classification, business needs, and legal requirements for these specific assets. And this is a business function. This is something you need to work with your business on. You, as a security professional, do not come up with this arbitrarily. There needs to be legal and compliance involved in these conversations. And then you need to document the retention schedule. This maintained a detailed detailed records outlining the duration of retention for each type of asset. Again, like we've made point time, point, and whatever I'm trying to say here, again and again. You need to document and make sure you have the documentation in place and maintained for your company. Retention risk, this is over retention. This happens a lot, right? There's I mean, you see people out there on shows called the hoarders. They hoard this, they hoard that. Well, it's no different with data. People are data hoarders, they hoard all All kinds of information and keep it way more and way longer than they should do. So this causes a lot of challenges, right? From increased storage cost, management overhead, and the red the security risks of having this data just sitting out there waiting to be pilfered. So over retention is a problem. Under retention, this is where you premature deletion of data, resulting in noncompliance, loss of critical records, or the inability to meet legal obligations. So if you get called about having your documents on legal hold, that is something that you should be very aware of. If you are listening to this podcast or this training, you know that legal hold is a big thing. You need to make sure your legal teams are telling you, hold on to that data, do not let it go, do not delete it, put it in a special place. Legal hold is an important part because that data becomes potentially a public record for any sort of litigation. So something to consider when you're dealing with that. So you don't want to go and just start deleting stuff if you do not understand the full ramifications of doing so. Retention technologies, there's different types of archiving solutions that's uh and automating the movement of data along long-term storage, versioning and backup, and this is ensuring that data is available in multiple states and formats for retention and compliance. So there's lots of different pieces there that are all available for you to make sure that you are make you are keeping the information as for a longer period of time. So, so what are some key best practices for end-of-support and end-of-life and asset retention? So, proactive monitoring, continuously monitor vendor announcements for end-to-support and end-of-life dates. I did this and I'd have this check on these at once a year. You had a time once a year that you would look at your end-of-support and end of life and then verify where we are at with that. You you would know you if you're keeping an active role of this, you figure that out. And then if you come across systems that you didn't know existed, which will happen, then you add them to this end of support and end of life list. Life cycle management, this is where you indicate life cycle management into asset procurement and maintenance process. So if you have a good process in place to buy stuff and maintain stuff, it will come up and you'll realize, okay, this one is coming up, end of life. I need to purchase a new one. So they're integrating all of that together, monitoring and life cycle management. You have compliance checklists. These checklists are used to ensure retention practices meet regulatory and organizational standards and that you are in connection with your compliance team. Obviously, periodic reviews are an important part. Like I mentioned earlier, I do this once a year. Uh, it it sometimes when we were I first started an organization that didn't really have this in the play in the past, then what I did was I would go and probably do it about once every three to four months just to kind of keep my eye on the ball. Once it became something where we had a pretty good idea of where all the data was and all of the systems were, we then went to a once-a-year type plan. Now, incident response plans, you need to have uh your incident response plans set for potential data breaches involving end-of-life systems. So, how are you gonna deal with that? And then if it does say, for example, this end-of-life system runs your widget factory that if it goes a breach occurs and you now are end of life, what are you gonna do? Do you have a backup to get this end-of-life system back up and operational? Uh uh, do you have a spare whatever? Or are you just gonna purchase and procure something new, which that would be extremely painful and would not be in a timeline that your business would want it to be up and going. So you might want to have the cannibalized Windows 95 box sitting on the side because if something bad were to occur to that one that you're you're currently using, you're gonna need a backup and very quickly. So, what is the importance of retention? So you have compliance and legal mandates, right? You have regulatory compliance, both HIPAA, SOX uh sox, which is Sarbanes Oxley, GDPR, all of those things, you must adhere to specific laws and regulations that mandate data retention. There are, we mentioned earlier, legal hold requirements from litigation, investigations. This needs to be kept in records until legal processes are completed. So you gotta keep it. Business continuity, you have operational needs, which ensures critical data and records are accessible for any ongoing operation and recovery in the event of an incident. And then you have audit and accountability. Maintaining these logs and records are incredibly important to support audits and demonstrate adherence to the various policies. So business continuity, compliance and legal mandates, and then finally historical and reference use. Keeping all this data is important for data analysis, right? If you don't have the data to be able to analyze, you maybe then are missing trends and other kinds of activities that could occur. I will say I would we were keeping data on PLCs, which is basically your logic controllers. Those are the things that are set up specifically around making the widgets run. They they flip a switch on and off. And these were using Arduino or some sort of kind of type product that was doing this activity. Well, they create data in of themselves. This data was stored. This data was also managed on pressures that came with it, sensors that were looking at pressures, temperatures, and so forth. And you then analyze this data would tell you when these systems might fail based on different types of data that's coming out of them, different types of activities. So data analysis is an important part, especially within any organization. Knowledge preservation, remaining system documentation and configurations for reference and future projects is an important aspect as well. So compliance, data, business continuity, and historical use are all important retention requirements. So the types of data that are subject to retention, user systems log, you know, security logs, any log that's tied to any sort of access control, authentication, any of these are designed to be kept for a period of time that support investigations and forensic analysis. Audit trails, these maintain a comprehensive audit trail to track in system configurations and administrative actions. And then application and database data. These are operational records that retain customer data, financial records, or other critical data as a business and legal requirements. And then finally, backups are an important part of any application and database. You want to make sure you have good, immutable backups for your information to be stored and protected long term. Last thing is system documentation. Configuration files and technical manuals are all an important part. So if you have configuration systems that are set up for your firewalls, for as an example, and you go and you say, all right, well, what happens if this firewall turns to a brick? Do I have another one? Yes, you do. And you spent, like, let's just say six weeks getting the right security, I shouldn't say security, but the right logs, the ACLs set up within your firewall. And now they it turned into a brick, and you've got to start from bare metal. Well, if you don't have the configurations on those various ACLs, you are gonna be in a really tough spot. So having the configuration file for that Fortinet firewall is an important piece that you can then turn around and just reinstall it. So you want to have all of that maintained and retained, as well as the technical manuals and change logs. So let's say, for example, you have an old system that you're keeping. You really would like to have the technical manuals on how to manage that system if there's something bad that occurs. So again, system documentation, important part. So types of assets that are subject to retention. You have data assets. This is user data, customer information, final financial records, personal data, all of that could be considered user data that it could be retained. System logs, these are your security and operational logs that are used for event tracking and conduct forensic evaluations. And then obviously your backup data that's stored for disaster recovery and business continuity aspects. Your physical and virtual assets, this is servers and hardware. Again, we talked about having configurations, but also having the different types, lists of hardware that you have within your organization as well. And this could also be an important part of any sort of regulatory or contractual obligations, obligations. Thank you. I can't speak. But one thing that is, I'm in the process of working with a financial institution right now. They are getting they're a highly regulated entity, and they are asking a lot of questions about the hardware and the software that are there. And they are asking what types of these? What are they, what is the name of them? What is their versioning? How old are they? So on and so forth. So all of that is an important part of maintaining and knowing that information. Storage media would be hard drives, tapes, and other data storage devices that may contain retained data. All of that is the storage stuff that you have within your company. Documentation and records, this is configuration and change management records, documents detailing system configurations and changes over time. This is where you make a change. You made a change to the firewall, and then when was the last change? And did you look at the last change? So these are all detailed system configurations and changes that are occurring over time, and this is you keeping the accurate records for that. And then operational and security procedures. This is manuals and guidelines that support the maintenance of these various security systems. So factors influencing retention requirements. So you've got obviously regulatory requirements that would be focused on this. Now, these regulatory requirements can be very different depending upon the localization of where these regs are at. So in many cases, HIPAA requires patient health information to be retained for at least six years, while financial records under SOX may require a retention for seven years. So you need to understand what are the requirements, both from a regulatory and legal standpoint. Now, local laws will vary, and we talk about international laws, they too will vary. So this is where you need to work with your legal teams to get a good grasp of what their retention schema looks like. Now you have business and operational needs. Again, I know from a historical standpoint, our many business units will keep their data for years and years, like 20 plus years. Now I I've worked with some of these folks saying, Can we do you have to keep it for 20 years? Then the hoarder in them comes out and says, Well, do we have if we get rid of it, we don't have it? And yeah, that's true, you don't have it. But do you really need it? And when was the last time you looked at it? And so, yes, you will, that'll be something you will go back and forth with. The bottom line, how you fix this is you go, okay, business unit, not a problem. Uh, this will cost you X thousands of dollars per month to maintain this data. Are you okay with it? And if they go, yeah, we're good with it, I said, okay, it increases the risk of X, which could cost you even more. Are you okay with it? Yeah, we're good with it. If they say that, great, proceed, not a problem. But the thing is, you need to bring that on to them of what it's going to cost by maintaining all of this information and this data. Risk management considerations, uh, you again, risk of data loss, it's an important part. Keeping, like I mentioned just a bit ago, keeping this data for a long period of time is not necessarily a good thing. It will end up causing you a lot of drama, and it could potentially lead you down to legal issues as well. Again, retaining the cost against the potential fines, you gotta understand, is that a problem? And this is a risk-based decision that you have to make. And actually, it probably won't be you making it, it will most likely be the senior leaders making this discussion this call, but someone's gonna have to make it. So, retention policies and schedule. So, your retention policy development, this you will create policies that outline the types of assets retained during storage uh durations, storage methods, and access controls. You need to have policies in place that have clear guidelines on what this should how long it should be kept and when should it be disposed of. You need to have retention schedules. These are categorized schedules defining the schedules based on data types and as well as periodic review and retention schedules to ensure alignment with the evolving legal and business requirements. And this, again, the business requirements change, and so therefore, you need to have this schedule set up probably at least annually that you're looking back at this. Exceptions and overrides, legal holds and public policy exceptions. So, legal holds we kind of talked about already, the ability to maintain this stuff for legal holds, but policy exceptions, you need to document and have approval for exceptions to any sort of policy when necessary. So, especially when it comes to retention, you gotta have, we I mean you just can't arbitrarily go, I'm the boss, and I'm going to say we don't need to do it. You okay. If you're the boss and you have the ability to do that, that's awesome, but then document it. Because if the regulators come in, they're gonna go, why does this gone? And you're gonna go, he did it. And and if you don't have the boss statement saying that he did it, then it could very well ride on your shoulders and they'll say, You did it. So, yes, it could very well happen, and it does. Challenges in risk um risk asset retention. We talked about over retention, keeping stuff too long, increased volumes of data can lead to significant storage and maintenance costs, kind of a big factor. Pass that on to your business units. They may then make some changes because they don't want to pay for it. Under retention, we talked about not having it kept long enough. That's where you deal with operational impact. Um, if you don't keep critical data long enough and you need that data, it can cause an outage or it can cause a problem when you know you need that information. So again, you need to maintain the retention between uh you balance it between retention and privacy is an important factor in this. And you need to ensure that if you are keeping this data for a period of time, uh that you do have strong access controls, encryption, and the pri uh and you protect the data from unauthorized access. So balancing the retention and privacy is an important part in any organization. Now, secure disposal procedures. You have data sanitization, documentation, and asset life management. So data sanitization is using secure methods such as data wiping, de-gausing, and physical destruction to ensure the data is irrecoverable. You can't get it back, it's all broken up. And this is where it's an important part of any company for doing this. And back to what I said before, you've got to maintain records of your data disposal. This the auditors will ask, they will look at this. If you have good records, they will move on to the next thing. If you don't have good records, they're gonna dig deeper. So documentation is important. They have no, these auditors have no way of knowing that you're doing a great job unless you document it. Now, if you document stuff and you're not doing it, they'll find that out too, and then that's even worse. Uh so asset life management. So tracking asset life cycles, this is where you're gonna be wanting to change that. And then your end-of-life planning, you're gonna also want to make sure that you have a secure decommissioning of all these systems and data storage devices at the end of their operational life. So, the best practices for asset retention, automated retention tools, utilizing software solutions to enforce retention schedules, monitor compliance, and minimize manual oversight. You also want to have employee training to help educate your staff on retention policies and the importance of complying with this. And then we talk about auditing and monitoring, again, coming back to it, ensuring that you are doing the right thing when it comes to compliance and identifying areas for improvement and then documenting all of these retention aspects. So, again, you probably see in this, you're going, you've said this a couple times now. Yeah, I'm trying to make sure you guys understand over and over again, this is the important parts of all of this. If you can get back to this, I have students that ask me saying, Well, I don't understand all this concept. This stuff is just overwhelming at times. And the content can be overwhelming, no question about it. However, the more you hear it and the more that it's repetitive, repetitive, that's not even a word, it's repeated, then you will then pick it up and understand it better. So, again, important parts in all of this aspects. All right, some key considerations for security professionals. Ensure policies are up to date, and this includes retention policies, should be reviewed and updated regularly to maintain compliant with current regs. Got it. Compliance monitoring, make sure you're paying attention to it and you have the retention practices aligned with your policies. And then you have cross-functional coordination. You work with legal compliance and IT teams to ensure you have a retention strategy that aligns to both regulatory and business objectives. So again, key points. Sure policies are up to date, compliance and monitoring, and then cross-functional coordination. Okay, so that's all I have for you today. I hope you have a wonderful day. You know, this is amazing stuff, great stuff happening at the CISSP Cyber Training. I hope you're getting into January and you're now gonna be ready to get your CISSP done. Let's knock it out. Let's get this thing done. So head on over to CISSP Cyber Training, and we can help you with everything that you need to be successful in your overall certification journey. All right, have a great day, and we'll catch you all on the flip side. See ya. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes. I would greatly appreciate your feedback. Also, check out my videos that are on YouTube, and just head to my channel at CISSP Cyber Training, and you will find a filter for a copia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 363 CISSP questions to help you in your CISSP journey. Thanks again for listening.

Contributor

Shon Gerber

Host