In this video, you will learn to describe which compliance policies most organizations are required to follow, described the use of audits in cybersecurity compliance. We go to compliance. Here's a quick example of couple of regulation or compliance policies that most of the organizations in the United States or in other parts of the world need to have or to implement in order to operate certain countries. So for example we have SOX. SOX is a financial compliance or financial regulation program. HIPPA, we already mentioned HIPPA. It's something related to healthcare, how the healthcare or organizations deal with the privacy of data of their patients, for example, how they transmit the data between hospitals, different healthcare organizations and for example, if they transmit the information in a secure way for example. GLBA is something related to finance. PCI/DSS, these are related to the manage of credit cards of financial processes. So if you want, for example, to start processing credit cards on your servers because you have an online store, probably you will need to comply with PCI/DSS. Normally, a lot of companies that deals with PCI/DSS, it's to perform, for example, Panthers or [inaudible] assessment on regular basis for them to comply with PCI/DSS. So here's just examples for their compliance. One of the last part that are important to understand is the main difference between the process that any organization could perform in order to identify if they are compliant with a certain regulation or a certain framework that they want to implement. One of the things that they need to perform is an audit. Now an audit could be an internal audit or it could be an external audit. The internal audit is obviously performed by internal departments, by internal audit department and that's something normal with most of the organizations. That's a continuing process, that's something that is normally performed during all the year, during audit life-cycle. But the difference here is normally the internal departments will generate reports but those reports are necessarily to improve the operation of the organization. The external audits are normally based on requirements. So for example, if you want to comply with PCI DSS you will need to hire an external audit company to generate a report and understand in which of the PCI DSS part you are not complying, or if you are complying in all that PCI DSS parts, while the external company will let you know on the report that you are able or you can go now and apply for a PCI DSS certification or process to be a part of or to start dealing with credit cards for example. Now here is a methodology which you could use in your audit projects for example. Basically these processes could apply for external and internal audits, but are actually pretty simple with three phases. But inside each of the phases, you will have a bunch of steps and again this is something to standard. So it not necessarily means that the same methodology will be applied or will be valid for all the organization. But this is just the baseline. So on phase one, you will have to understand the organization view, you will need to understand the organization that you are dealing with, you will need to identify the key players, the key users for example of system in motive to start looking for any finding, any incident or issue that you may report in your final audit report. Also you will need to create a profile, you will need to create a threat profile. For example if you are auditing a software, you will need to understand well, this is a web-based software and one of the threats that the software could have, is cross-site scripting attack. So it doesn't mean that the software that you are auditing right now is prone to or have an issue regarding cross-site scripting. But that's something that in phase number two and phase number three, you will need to assess and you will need to identify. So again if you know that you are dealing with a web page or the web software will be prone to a cross-site scripting attack. On phase number two, you will need to evaluate, you will need to understand and you will need to debt or probably interview to the creators of software and ask if they are already perform any kind of app for example, Security Review on the web system, on the web application and the results of the review will have something regarding cross-site scripting. If there is any security review for that web system, probably you will need to create your own test, your own assessment or you will need to inform on your report that this software doesn't have any security review. That will guarantee that is truthful for example and the last part is the risk assessment. The risk analysis. That process will translate all your findings in your audit report, into a risk. This could be on the example that we are talking about the cross-site scripting, if you detect that the organization is not performing any security assessment and you don't have any widths or any evidence that will let you know that, yes, this software is not prone to cross-site scripting. Well. You need to categorize that finding into a risk. Is this a high risk for your organization? Well. If your business depends on that web system probably it's a high-risk, probably it's a critical risk. So you will need to understand, you will need to translate those findings into risk.
