Introduction
All system elements are vulnerable to some degree. Thus, in any situation, at least a cursory pre-implementation risk assessment should be performed. Some factors, like power issues, endanger all of the components and should always be considered before the new technology is implemented. Of course, certain factors make per-implementation assessment even more important. If a new component is critical to the whole architecture, it should be checked extensively for any potential risks. If the new solution is used to deal with the sensitive company data, potential external threats should be evaluated especially carefully. A good example of the pre-implementation assessment importance is presented by the power outage in Virginia which has wiped 13% of the data servers in the Commonwealth (Mearian, 2010). While the power company has assumed blame for the incident, it is clear that the necessary precautions were not taken by the server owners, indicating the lack of proper risk management. Taking power problems into consideration is a basic stability requirement, but even it can be overlooked if the risk assessment is ignored or poorly performed.
Main body
Post-implementation checks are aimed to make sure that the new architecture is working as intended. Such evaluations should always take place after the new technology or software is introduced. In most cases, a brief review will be enough, but these assessments are especially important when the innovation causes changes to the workflow and requires the employees to be educated on the new techniques and procedures. People are always the most vulnerable and unpredictable part of the system. Identifying potential problems in such cases should be a priority. As with any changes an extensive review is warranted when the consumer data is concerned. My friend has worked for a company which ended up accidentally opening access to sensitive customer data to all employees. It was a result of technicians not revoking the access privileges properly. Such cases highlight the necessity of post-implementation reviews.
As with the pre-implementation assessment, periodical review of risks after a piece of architecture was implemented is a necessity in any situation. It is especially true for the external threats since new malware, and hacking methods are constantly being developed. These programs can present a threat even in a situation when no changes to the system were made. If the company can potentially attract the attention of the cyber criminals, the risk assessment should be one of the top priorities. This is especially true for the companies processing customers’ personal information since the loss of such data can be absolutely disastrous and endanger the entire company. Most of the internal risks, on the other hand, should become apparent during the initial assessment. But all of the preventative measures must also be checked regularly. A perfect example of the risks of poor post-implementation risk assessment is presented in the Computer World magazine. A new piece of ransomware called Locky has infected 75% of the computers in an unnamed company. The virus spread through a Word document macros, and the situation was easily preventable if the employees were following the proper security protocols and instructed to keep up-to-date backups (Rice, 2016). Regular checks make sure that all the precautions are in place, and such situations do not occur.
Third party components are always a vulnerable part of the system architecture. Since the end-user does not possess full insight into the process of the software or hardware creation, the external additions to the system are less predictable. That should be accounted for in pre-implementation assessment. It also means that third-party components need to be reviewed more often. In the case of software, a new version should always prompt a reassessment. With hardware, it is harder to determine the exact intervals, but new additions to the system affecting a third-party component are a good reason for another review. It is also important to consider that almost every business uses third-party applications in one way or another. For example, Google is used in almost every company. And it can present a security threat, just like any other piece of software used by the company. With Google recently admitting a potential security risk, it makes reassessment necessary (“Google Warns Users About Having a Security Breach,” 2016). It is important to constantly keep track of the changes to the third-party components of your system. Since the user has no control over those innovations, it is crucial to monitor them and review the security risks.
Conclusion
Ideally, you would want the corporate management to keep track of the changes in the security situation. However, that is hardly possible in most cases. Submitting regular monthly reports is important, but the crucial part of communicating with management is making sure that the serious changes to the security situation are noted. It is important to focus on reporting the changes as they occur and making sure the risks are noted, and the precautions are being taken. These factors are the most important ones in communicating with the company governance. A report in Wall Street Journal confirms that not being able to effectively communicate with the superiors is a great risk to cybersecurity by itself (Yadron, 2014). That is why in my opinion reporting often is not as important as reporting clearly and efficiently.
References
Mearian, L. (2010). Northrop Grumman takes blame for Va. IT services outage.Computer World. Web.
Rice, J.F. (2016). When Locky strikes.Computer World. Web.
Google Warns Users About Having a Security Breach. (2016). The Weekly Observer. Web.
Yadron, D. (2014). Miscommunication as a Cybersecurity Threat.The Wall Street Journal. Web.