Process Risk Self-Assessment (PRSA) is about performing an examination of potential process risks and then ensuring controls are written and tested in order to mitigate those risks until they can be remediated.
Many larger corporations have a Risk Management, CISO (Chief Information Security Office), Compliance, or Internal Audit Office. These organizations regularly audit and provide oversight for ITSM processes. Commonly, these organizations have access to lists of industry standard risks and general controls for each process. Some examples of industry-wide controls include: segregation of duties within the process, access control and validation, and others.
The first step in creating a process-level PRSA is to obtain a list of these industry-wide general controls or process related risks from the organization responsible for internal audit, compliance, risk management, or CISO at your company. If your company does not have a list of these industry-wide risks; as was recently the case in an organization I worked with; go to your company Information Technology Policies and Directives and read through them. It will be clear what kinds of risks the company has already identified. For example, most companies have policies and directives around information security and protection of information. There may be policies regarding protected types of information. There will certainly be policies and directives around controlling access. In Health Care, protected information would be patient information. In the Financial Services sector, it would be card holder information. Sensitive information that should not be entered into a process (incident) record needs to be identified.
Once you have a list of industry standard risks and general controls, you then examine each activity in the process and determine the risks of process failure, compromise, or operational ineffectiveness for each activity. For instance, what if there is a field in the incident record which does not have a drop-down selection, and choices cannot be predetermined; such as an incident record work-log. The work-log for each incident should contain an entry for each milestone activity performed while diagnosing, testing, implementing, and validating service restoration of the incident. From the work-log, one should be able to reconstruct a chronological timeline of events as they occurred. There should be no protected information logged into the work-log of the incident; especially if there is general read access to these records and they are stored for longer periods of time for business purposes. When you train process practitioners, you train them how to properly complete the work-log, what information to enter into it, and what information should be restricted. However, there remains a risk to process efficacy, and compliance with corporate policies and directives; that anyone entering information may enter protected information. This is a risk because entry of this information violates IT policy, exposes the company to the risk of misuse of the information, and litigation. Go through the process and identify all such risks in any activity of the process. Make a list of them.
Now you have a list risks from both categories (1. Industry-standard/general controls and 2. Process specific). Put the list on a spreadsheet and now add a column, and for each risk add a priority based on the likelihood the risk is to be realized as well as the impact to the organization and process if it is. Add another column that aligns each risk with the name of the industry-standard or process specific risk. For instance, if there is a policy in your company related to protected information, these will generally have a policy number. That number will be entered into the column for the risks on your list that relate to it. Alignment of the risks to policies and directives can be a many-to-one relationship. There could be an identified risk on the list that aligns to multiple policies and directives.
The succeeding step is to take the highest priority items on the list (those with the most risk) and write a control for each. Generally this is done by the Process Manager and Owner working together with Risk Management, CISO, Leadership, Compliance, and Internal Audit organizations. Each control has the following data elements:
- Title of the risk.
- General Control, Industry-standard risk, Policy, or Directive alignment.
- Description of risk
- Priority of risk
- Impact of risk (high, medium, low) (Brand damage, litigation, financial damage, process efficacy, &c..)
- Likelihood of risk occurring (high, medium, low)
- Mitigation and testing
- Frequency of testing
- Method of testing (procedure)
- Evidence of testing
- Pass/Fail Criteria
- Pass/Fail Actions
An example of a single Control is:
|Control Title: Protected Information must not be entered into Incident Records|
|Alignment with Information Technology Policy IT-010-001.20 – Protected Information|
|Description: Ensure protected information is not entered into incident records.|
|Priority: 10 – Likelihood: Medium|
|Mitigation and testing – Mandatory Incident Management training is provided by the Process Owner for each new employee utilizing the process. This training teaches and reinforces the Information Technology Policies and Directive regarding protected information and utilizes the definitions for what constitutes protected information defined within the associated policies and directives. Records will be sampled on a regular and ongoing basis and inspected for protected information. If protected information is identified, the test will Fail and Pass/Fail Actions completed. The definition of what types of information is protected is defined within Information Technology Policy IT-010-001.20.|
|Frequency of testing – Testing shall be conducted on a monthly basis on the last Wednesday of each month.|
|Method of testing – 100 incident records shall be extracted from the Incident Management database. This list should not include any records previously extracted or tested. Fifty of these records shall be randomly selected and evaluated against the defined Pass/Fail criteria.|
|Evidence of testing: The following artifacts shall be available:List of 100 records extracted from the Incident Management Database.List of 50 records randomly selected from the list of 100 incidents extracted from the Incident Management Database.Testing date/time, results of testing and designation of Pass/Fail for each of the fifty randomly selected incident records.
A designation of Pass/Fail for the control each month
Review signoff by the Tester, Reviewer, and Approver roles
Evidence of Pass/Fail Actions completion
History of all individuals / groups involved in testing failures in the past year
|Pass/Fail Criteria: The Control shall be considered as Passing if Control testing is performed at the prescribed times. The control test shall Pass if no protected information is identified within any of the randomly selected incident records evaluated. The control test shall Fail if protected information is identified within any of the randomly selected incident records evaluated.|
|Pass/Fail Actions:Failure Actions:First occurrence for an individual/group within one year: For each record identified as containing protected information, send email to the Manager of the person(s) who entered the information into the incident record requesting that within one day, they immediately edit the record to remove the identified protected information and that within one week they provide assurances to the Process Manager that the individual(s) who entered the information is counseled regarding:The applicable Information Technology Polices pertaining to appropriate use of protected information and what constitutes protected information.
What information is not authorized to be entered into incident records
The proper method for completing incident records during the lifecycle of an incident.
Second occurrence for an individual/group within one year: For each record identified as containing protected information, send email to the Manager and Director of the person(s) who entered the information into the incident record requesting that within one day they immediately edit the record to remove the identified protected information and that within one week they complete mandatory Incident Management training for the individual(s) who entered the information. Proof of completion shall be sent to the Process Manager. Mandatory Incident Management training is provided by the Process Owner.
Third occurrence for an individual/group within one year: For each record identified as containing protected information, make contact with Risk Management, Internal Audit, and the Vice President of the person(s) who entered the information into the incident record requesting that within one day they immediately edit the record to remove the identified protected information and that the individual be placed on a Performance Improvement Plan within one week. The Performance Improvement Plan must state that no further instances of this behavior be observed for one year, or consequences can include employee separation from the company. Within one week the Manager and Director the individual(s) who entered the information reports to shall complete mandatory Incident Management training. Proof of completion shall be sent to the Process Manager. Mandatory Incident Management training is provided by the Process Owner.
Fourth occurrence for an individual/group within one year: Immediate escalation to Human Resources. Separation or reassignment of the individual(s) or groups. Immediate revocation of access to the Incident Management application and repository.
Pass or Fail Actions: Results of testing shall be published to IT Leadership and reviewed with process Core Stakeholders during scheduled Service Reviews.
|Roles:Process PRSA Control Tester: Process Analyst.Process PRSA Control Reviewer: Process Manager.Process PRSA Control Approver: Process Owner|
For each control there will be a role in the process owning organization performing the test(s), a role reviewing the results of the tests; scheduling and completion of Pass/Fail Actions, and a role approving testing results, certifying that tests were completed, and the Pass/Fail Actions are completed. These are generally a Process Analyst, Process Manager, and Process Owner respectively.
The level of detail describing the Control data elements needs to be explicit enough so that it is clear and auditable. Control testing evidence, evidence of completion of the Control(s) as well as Pass/Fail Actions, and signoffs must be stored in a secure repository and made available to auditors and regulators should they request this information.
Different controls can be tested with different frequencies; some annually, quarterly, or monthly. Control testing completion and results can be reviewed with Core Stakeholders during the Service Review.
It goes without saying that once Controls are written, and prior to implementing them, the Process Owner should review these with Leadership, Internal Audit, Risk Management, Core Stakeholders, Compliance, and/or CISO to gain alignment and consensus.
Once established, the Process Owner realizes the benefits of continued support from IT Leadership because they understand that the process is compliant and aligned with corporate policies and directives, general risks identified in the industry as a whole, and more importantly, that the process is audit-ready with as much risk identified and mitigated as possible.