Sample Company
Revision History DATE VERSION DESCRIPTION AUTHOR 08-07-04 0.01 Initial Version F. Jack Anderson 09-07-04 0.02 Revised with changes from team reviews Michael Bennett 09-08-04 2.00 Initial Baseline Michael Bennett 12-6-04 2.01 Edit to ensure consistency and clarity Joy Ulrich 03-09-05 2.02 Accepted Joy s changes F. Jack Anderson 06-03-05 3.00 Baseline Michael S. Bennett 12-05-05 3.01 Format and style changes. Grammar changes as found. Jan Shearer Confidential Sample Company Page 2 of 22
Document Approval The signatures below indicate approval of the scope and content of this document. Any changes to this document after initial approval will be performed in accordance with the Novus Configuration Management Plan. NAME/TITLE SIGNATURE DATE F. Jack Anderson Author Sample Novus Project Manager Sample Novus Lead Business Analyst Sample Novus Technical Lead Sample Novus Senior Tester F. Jack Anderson Regulatory IT Quality Assurance Lead Confidential Sample Company Page 3 of 22
Table of Contents 1 INTRODUCTION... 6 1.1 PURPOSE... 6 1.2 SCOPE... 6 1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS... 6 1.4 REFERENCES... 6 1.5 OVERVIEW... 6 2 RISK IDENTIFICATION AND ASSESSMENT... 7 3 HIGH-RISK LIST... 8 3.1 LACK CONTROL OVER THE PQ TEAM SCHEDULE... 8 3.1.1 Description... 8 3.1.2 Impact... 9 3.1.3 Indicators... 9 3.1.4 Mitigation Strategy... 9 3.1.5 Contingency Plan... 10 3.2 INSUFFICIENT STAKEHOLDER PARTICIPATION... 10 3.2.1 Description... 10 3.2.2 Impact... 10 3.2.3 Indicators... 11 3.2.4 Mitigation Strategy... 11 3.2.5 Contingency Plan... 12 3.3 SCOPE CREEP... 12 3.3.1 Description... 12 3.3.2 Impact... 12 3.3.3 Indicators... 12 3.3.4 Mitigation Strategy... 13 3.3.5 Contingency Plan... 13 3.4 INSTABILITY OF SOFTWARE VALIDATION PROCESS... 13 3.4.1 Description... 13 3.4.2 Impact... 13 3.4.3 Indicators... 13 3.4.4 Mitigation Strategy... 14 3.4.5 Contingency Plan... 15 3.4.6 Description... 15 3.4.7 Impact... 15 3.4.8 Indicators... 15 3.4.9 Mitigation Strategy... 15 3.4.10 Contingency Plan... 16 3.5 INABILITY TO INTERFACE WITH EXISTING SYSTEMS... 16 3.5.1 Description... 16 3.5.2 Impact... 16 Confidential Sample Company Page 4 of 22
3.5.3 Indicators... 16 3.5.4 Mitigation Strategy... 16 3.5.5 Contingency Plan... 16 3.6 CANCELLATION OF I-ADVANTAGE CONTRACT... 17 3.6.1 Description... 17 3.6.2 Impact... 17 3.6.3 Indicators... 17 3.6.4 Mitigation Strategy... 17 3.6.5 Contingency Plan... 17 3.7 BUREAUCRATIC PROCESS AND REVIEW OVERHEAD... 17 3.7.1 Description... 17 3.7.2 Impact... 18 3.7.3 Indicator... 18 3.7.4 Mitigation Strategy... 18 3.7.5 Contingency Plan... 18 3.8 LACK EXPERIENCE WITH REGULATED ELECTRONIC SYSTEMS... 18 3.8.1 Description... 18 3.8.2 Impact... 18 3.8.3 Indicators... 18 3.8.4 Mitigation Strategy... 19 3.8.5 Contingency Plan... 19 3.9 UNKNOWN DEFECTS OR INCOMPATIBILITY AMONG PRESCRIBED PROJECT TOOLS... 19 3.9.1 Description... 19 3.9.2 Impact... 19 3.9.3 Indicators... 19 3.9.4 Mitigation Strategy... 19 3.9.5 Contingency Plan... 20 3.10 INSTABILITY OF THE OPERATING SYSTEM (OS)... 20 3.10.1 Description... 20 3.10.2 Impact... 20 3.10.3 Indicators... 20 3.10.4 Mitigation Strategy... 20 3.10.5 Contingency Plan... 20 3.11 LACK ORGANIZATIONAL CONTROL OVER SECURITY OF COMPANY-CONFIDENTIAL INFORMATION... 21 3.11.1 Description... 21 3.11.2 Impact... 21 3.11.3 Indicators... 21 3.11.4 Mitigation Strategy... 21 3.11.5 Contingency Plan... 21 ATTACHMENT A - RISK ASSESSMENT CRITERIA... 22 Confidential Sample Company Page 5 of 22
1 Introduction 1.1 Purpose 1.2 Scope This is the implementation of the Risk Management Plan, which is described in the Novus Software Development Plan. During the Inception phase of the Novus project, the Novus development team identified and assessed significant risk factors associated with the development of the system. A risk exposure score was then calculated for each risk (See Attachment A - Risk Assessment Criteria). For risks with a risk exposure score of four or greater, mitigation and contingency plans were defined. This plan was developed specifically for the Orion project, which involves the development of a regulatory sample management system. Several of the identified risks apply to software development projects in general. Therefore, this plan may serve as the foundation for other Novus software development projects. 1.3 Definitions, Acronyms, and Abbreviations See the Project Glossary for a complete list of definitions, acronyms, and abbreviations associated with Novus projects. 1.4 References 1.5 Overview Novus Software Development Plan The remainder of this document is organized as follows: Risk Identification and Assessment Summarizes the list of risks discussed in the initial risk assessment meeting and the assessment of each. High-Risk List Identifies those risks with a risk exposure score of four or greater and outlines the plan for mitigating those risks. The list also includes contingency plans that identify how problems will be handled should a risk materialize. Confidential Sample Company Page 6 of 22
2 Risk Identification and Assessment The following table summarizes the risks identified during the initial risk assessment and the overall risk exposure for each. A description of the risk assessment criteria is provided in Attachment A - Risk Assessment Criteria. RISK DESCRIPTION PROBABILITY IMPACT RISK EXPOSURE Lack of control over the PQ team s schedule Highly Likely Catastrophic 6 Insufficient stakeholder participation Highly Likely Critical 5 Scope creep Highly Likely Critical 5 Instability of the software validation process Resources not available when tasks are scheduled to start (human and equipment) Inability to interface with existing systems Highly Likely Critical 5 Highly Likely Critical 5 Probable Critical 5 Cancellation of i-advantage contract Highly Likely Critical 5 Bureaucratic process and review overhead Lack of experience with regulated electronic systems Unknown defects in or incompatibility among the prescribed project tools Highly Likely Critical 5 Highly Likely Critical 5 Highly Likely Marginal 4 Instability of the Operating System (OS) Probable Critical 4 Lack of organizational control over the security of company confidential information Tasks incorrectly defined in, or omitted from, the software development process Project schedule does not include RFP process Probable Critical 4 Probable Marginal 3 Improbable Critical 3 Confidential Sample Company Page 7 of 22
RISK DESCRIPTION PROBABILITY IMPACT RISK EXPOSURE Schedule compression (e.g., Upper management decides that the project needs to be delivered earlier) Unexpected loss of resources (e.g., a key player wins the lottery and quits) Improbable Critical 3 Improbable Critical 3 Serious bugs found during testing Improbable Critical 3 Loss of work due to unexpected disaster (e.g., disk failures, power loss, sabotage, etc.) Unknown defects in or incompatibility between OS and layered products Budget is being consumed faster than expected Management change results in loss of senior management support Improbable Critical 3 Probable Marginal 3 Improbable Marginal 2 Improbable Marginal 2 Unexpected regulation change Improbable Marginal 2 3 High-Risk List Table 1 - Risk Assessment This section provides more detail about those risks with a risk exposure score of four or more. The probable impact of each risk, and the steps that will be taken to avoid or minimize the risks, are also described. 3.1 Lack Control Over the PQ Team Schedule 3.1.1 Description This risk has a probability rating of Highly Likely because it reflects the current state of affairs for this and other projects. In prior projects, the PQ protocol was executed by a representative group of end users and the Project Manager had no control over the schedule for this phase of the project. Timely execution of the Performance Qualification protocol is crucial to maintaining the project schedule. Historical evidence suggests a strong likelihood that this risk will materialize, if not mitigated. Confidential Sample Company Page 8 of 22
3.1.2 Impact The inability to influence the schedule for this phase of the project could result in substantial schedule and cost over-runs. 3.1.3 Indicators Indicators that this risk could materialize are: Dedicated resources for this phase of the project are unavailable or unscheduled at the start of the phase Review of documentation prior to execution takes longer than scheduled Execution of PQ test cases takes longer than scheduled 3.1.4 Mitigation Strategy 3.1.4.1 Increase Awareness The Novus Project Manager will ensure high visibility of this issue by engaging the user representatives and Project Directors in risk mitigation tactics early in the project life cycle. 3.1.4.2 Tie PQ Schedule and Deliverables to Participants DPR One proposed mitigation strategy is to include the PQ schedule and deliverables as evaluation criteria in the participants DPR. Since no Novus project team members have direct influence over the content of participants DPR evaluation criteria, this strategy would require the approval of the Project Directors. 3.1.4.3 Verify Resources and Schedule in Construction Phase The Software Quality Assurance plan provides for project reviews and audits at the end of each phase of development. The exit criteria for each phase include verifying that all necessary resources are available and in-place for the successful execution of the following phase. The exit criteria for the Construction phase will be amended to include the following verification activities: Ensure that the schedule for PQ activities has been established Verify that the participants have been reassigned from routine responsibilities for a period of time sufficient to allow them to complete their assigned PQ responsibilities Confidential Sample Company Page 9 of 22
3.1.4.4 Weekly Progress Reports For the duration of PQ testing, the Superuser Team Lead will participate in the weekly Project Directors meeting to submit status reports on the progress of PQ execution. 3.1.4.5 Management of Review and Approval Cycles To minimize the impact of the review and approval process on the PQ schedule, documents to be reviewed will be distributed simultaneously to all reviewers, Reviews will be done in parallel and comments will be consolidated at a scheduled meeting of the reviewers. Reviewers edits will be made in real-time during the course of the meeting. The objective of this meeting will be to print a final approved version that is ready to be signed. This will ensure that all reviewer comments are discussed and any conflicts among reviewer edits are resolved. This process should allow the final draft to be approved in one review cycle. 3.1.5 Contingency Plan In the event that PQ testing falls behind schedule to the extent that it might have a material impact on the Project Contract, the Project Manager will convene the CCB. A CCB Change Request Evaluation form will be submitted to the Project Directors to request appropriate schedule and resource adjustments. 3.2 Insufficient Stakeholder Participation 3.2.1 Description The Elaboration phase, when the desired functionality of the system is identified and defined in detail, demands considerable time and effort on the part of Superusers (a Superuser is a representative of a larger end-user community) and the represented end users. The following factors contribute to an increased risk of inadequate participation by Superusers and end users: Competing priorities and time constraints limit the Superusers and end users ability to participate Assignment of Superusers is made on the basis of availability, instead of subject matter expertise Collaboration between a Superuser and the represented end users is inadequate or ineffective 3.2.2 Impact Features and functions of the final product fail to meet end-user expectations Confidential Sample Company Page 10 of 22
Revisions and adjustments during the Construction phase result in significant schedule over-runs Essential functionality goes unrecognized or is recognized too late in the project to make revisions Interfaces to other systems may be overlooked 3.2.3 Indicators Poor attendance or insufficient participation at requirements sessions or requirements review meetings Unexpectedly lengthy requirement elicitation meetings Numerous iterations of use case elaboration cycles Numerous requests for changes during Beta testing 3.2.4 Mitigation Strategy 3.2.4.1 Secure Users with Adequate Subject Matter Expertise The Superuser Team Lead and the Regulatory Co-Manager for the project will assign end users to work with the developers on the basis of their subject matter expertise and not based solely on their availability. 3.2.4.2 Superuser Team Education Early in the Elaboration Phase, the Superuser Team Lead will devote a portion of one Elaboration session to educating the Superuser group about the prevalence of this problem in past projects, the potential impact if the risk materializes, and how they can help to mitigate it. 3.2.4.3 Superuser Team Support One of the responsibilities of a Superuser Team member is to collect and compile feedback regarding system requirements from other end users in their group. To assist members of the Superuser team in meeting these responsibilities, the Technical Team will provide the following support: A schedule for the Elaboration sessions will be provided to Superuser Team members early in the Elaboration phase to allow them sufficient time to make schedule adjustments and reconcile competing priorities The Lead Business Analyst and the Superuser Team Lead will provide Superuser Team members with the following items to support these responsibilities: A task list Confidential Sample Company Page 11 of 22
A list of deliverables A RACI chart An agenda to guide Superuser Team members in collecting feedback from subject-matter experts and other end users 3.2.5 Contingency Plan If the realization of this risk is discovered early in the Elaboration phase, the Lead Business Analyst can discuss the issue with the Superuser Team Lead and agree upon an appropriate course of action. However, because the end users are the subjectmatter experts, the Technical Team heavily relies on end-user feedback to design the system. As a consequence, the fact that the appropriate subject-matter experts are not available often goes unrecognized until the Construction Phase, when end users begin to work with prototypes of the system. If this risk arises at this point in the project, the resultant impact will be escalated to the Project Directors, who will make the final decision as to whether: The project schedule and resources should be adjusted to accommodate changes to the system design, or The system will be deployed as designed and the requested design changes will be deferred and implemented in a subsequent system upgrade. 3.3 Scope Creep 3.3.1 Description Orion was originally conceived to address a specific set of core features to support specific business processes. Scope creep occurs when end users request functionality that is outside the intended scope of the project. 3.3.2 Impact Substantial cost and schedule over-runs Expensive features and functions that are rarely used because they do not correspond to or support a well-defined process are incorporated into the final product Extensive support services, and difficulty developing future upgrades and interfaces because the final product is excessively complex 3.3.3 Indicators Requests for functionality that is outside the scope of the project, which is defined in the Project Charter Requests for functionality for which no historical need can be established Confidential Sample Company Page 12 of 22
3.3.4 Mitigation Strategy As a standard quality control mechanism, Novus projects are required to maintain traceability between requirements, design, and source code components. Consequently, each functional requirement defined in the Elaboration phase must be traceable back to a statement or element in the project contract. To further mitigate this risk, any request for functionality that is not directly traceable to a statement or element in the project contract will be escalated to the Project Directors for the review and approval. The approval of such a request would then constitute a materialization of this risk. 3.3.5 Contingency Plan If the Project Directors approve a request for functionality that falls outside the scope of the original Project Charter, the Project Charter will be amended to reflect the expanded scope. The project schedule and resources will be re-evaluated and revised to support the additional functionality. 3.4 Instability of Software Validation Process 3.4.1 Description Software validation is a relatively new discipline within the TCC Regulatory division. At present, a validation standard does not exist, and lines of authority and responsibility for computer system validation are under development. Consequently, wide variances in the approach to validation exist between projects. 3.4.2 Impact Schedule over-runs during the Qualification phase of the project Errors in execution of validation protocols Citations issued for insufficient quality assurance measures (e.g., insufficient validation testing or discrepancies in validation documentation) by a regulatory agency based on an audit 3.4.3 Indicators Insufficient supporting documentation or errors in protocol execution documentation. Confidential Sample Company Page 13 of 22
3.4.4 Mitigation Strategy 3.4.4.1 Coordination Between TCC QA and Regulatory QAU Prior to the start of the Qualification Phase, the TCC QA representative and the Regulatory QAU representative will schedule one or more collaborative sessions to develop uniform testing practices and policies to be used for Novus validation activities. The Qualification Plan will be updated to reflect the outcome of these meetings as needed. The OQ and PQ testers will be trained in these practices and policies. The following paragraph describes how that training will be accomplished. 3.4.4.2 QA Training in Computer Systems Validation At the beginning of the Qualification Phase, the TCC QA and QAU Regulatory representatives will conduct a joint training session for OQ and PQ testers. In this training session, testers will be introduced to the Novus Qualification Plan, which contains extensive and explicit instructions for the execution and documentation of validation test cases. The training session will include: An introduction to the Novus Qualification Plan A test execution practice session designed to provide the OQ and PQ testers with hands-on experience in protocol execution. 3.4.4.3 QA Assessment of Tester Proficiency At the end of the test execution practice session, the testers performance will be evaluated and documented on a Tester Assessment Checklist, which will be developed based on the Qualification plan. Testers will be permitted to execute test protocols only after they have demonstrated proficiency in protocol execution techniques. 3.4.4.4 Mentoring by TCC QA and Regulatory QAU During Initial Test Execution As a further source of guidance, the TCC QA Representative will observe and mentor first-time OQ testers to ensure that validation tests are properly executed and documented. Similar mentoring will be provided by a Regulatory QAU representative to end-users who execute PQ test scripts. 3.4.4.5 On-going Collaboration Between TCC QA and Regulatory QAU During Qualification Phase We expect most of the errors and obstacles to occur early in the execution of OQ and PQ test cases. The TCC QA representative will convey information to the Regulatory QAU representative regarding errors and obstacles encountered during OQ test execution to minimize the occurrence of similar errors during PQ test execution. Confidential Sample Company Page 14 of 22
3.4.5 Contingency Plan In the event that errors and obstacles encountered during the Qualification phase result in schedule deviations that might have a material impact on the Project Contract, the Project Manager will convene the CCB. A CCB Change Request Evaluation form will be submitted to the Project Directors to request schedule and resource adjustments. 3.4.5.1 Resources Not Available When Tasks Scheduled to Start (Human and Equipment) 3.4.6 Description 3.4.7 Impact At the start of each phase of the project, specific resources must be in place to support the scheduled tasks for that phase. If required resources are not available, the project may come to a stand-still until they are acquired. If required resources are available, but in insufficient quantities, the schedule could slip significantly. 3.4.8 Indicators Long approval cycles for resource acquisition Longer than expected lead times for resource acquisition 3.4.9 Mitigation Strategy The Project Manager will maintain a resource management schedule for each type of resource. The management schedule will specify: When resources will be required The acquisition lead-time The approval cycle time The timing of resource requisitions submissions will be based on these factors. Requests for acquisition of resources will include an Approval Required By date to alert approval signatories of schedule constraints. Confidential Sample Company Page 15 of 22
3.4.10 Contingency Plan As a quality control measure, the TCC QA representative conducts an audit of the project deliverables, and a review of the activities and processes executed during the phase. This audit includes end-of-phase exit criteria, one of which is that the resources required for the next phase of the project be in place and properly installed (or, in the case of human resources, properly trained) before the present phase can be closed. 3.5 Inability to Interface with Existing Systems 3.5.1 Description The system under development will require interfaces to a number of existing systems. Although considerable effort has been devoted to identifying interface requirements to significant systems, the large number of systems within Monsanto precludes consideration of all potential interfaces. 3.5.2 Impact A manual interface between the two systems would be required Substantial schedule overruns could occur if design changes are implemented. 3.5.3 Indicators This risk could materialize in two ways: The need for an interface to an existing system is identified in the design phase, but cannot be developed because of incompatible software or hardware platforms. The need for an interface to an existing system was not anticipated and, consequently, was not included in the design of the system. 3.5.4 Mitigation Strategy There are no practical options for mitigating this risk. 3.5.5 Contingency Plan For scenario 3.7.3a, the only practical solution is to implement a manual interface between the two systems. Scenario 3.7.3b constitutes a risk only if the interface requirement is discovered late in the Elaboration phase or during the Construction phase. In this case, a manual interface can be implemented as a short-term solution. Then the automated interface can be incorporated in a future system upgrade. Confidential Sample Company Page 16 of 22
3.6 Cancellation of i-advantage Contract 3.6.1 Description The i-advantage system is a commercial software application that tracks protocol data and sample collection information for field studies. The Monsanto Electronic Field Trial Notebook (eftm) team is currently evaluating the i-advantage system and will make a recommendation in the near future regarding its future application at Monsanto. If the i-advantage system is retired, the Novus Orion project may be expected to include a subset of the i-advantage functionality in its design. The addition of such functionality would significantly expand the scope of the project. 3.6.2 Impact Significant increase in resource requirements Significant schedule over-runs 3.6.3 Indicators Final decision of the Monsanto eftm team. 3.6.4 Mitigation Strategy No mitigation plan can be proposed. The risk is entirely outside the control of this project. 3.6.5 Contingency Plan The Novus Project Manager is monitoring the progress of the eftm team. If it appears that the scope of the Orion project will be expanded to include features and functions in i-advantage, this issue will be escalated to the Project Directors for review and approval. If the Project Directors approve the inclusion of i-advantage functionality in the Orion project, the Project Charter will be amended to reflect the expansion of scope. The project schedule and resources will be re-evaluated and revised to support the expanded scope. 3.7 Bureaucratic Process and Review Overhead 3.7.1 Description The proposed application will provide features and functions that support a number of business processes that cross several organizational boundaries. Those business units that will use the system must participate in the design of the system, and will be expected to review and approve the final design. The time required for the review and approval cycles will have a direct impact on the project schedule. Confidential Sample Company Page 17 of 22
3.7.2 Impact 3.7.3 Indicator Realization of this risk would result in significant schedule overruns. Review cycles consistently running over schedule. 3.7.4 Mitigation Strategy Products that need to be reviewed will be distributed simultaneously to all reviewers, Instructions to review the product, mark their comments, and be prepared to consolidate the comments at a meeting planned for a future date will be included in the review materials. At the review meeting, reviewers will submit and discuss their comments. Any inconsistencies or disagreements between reviewers will be resolved in the meeting. The final modifications to the product under review will be established and agreed upon during the meeting. 3.7.5 Contingency Plan Schedule overruns that result from materialization of this risk will be escalated to the Project Directors before they have a material impact on the Project Contract. 3.8 Lack Experience with Regulated Electronic Systems 3.8.1 Description 3.8.2 Impact Statutory regulations prescribe specific functional characteristics and extensive quality assurance measures for electronic systems that will be used to maintain regulated data. TCC Regulatory has very little prior experience developing systems in a regulated environment. A subsequent remediation effort would be required to bring system features and functions up to regulatory standards. 3.8.3 Indicators There are no practical indicators to forecast the materialization of this risk. Confidential Sample Company Page 18 of 22
3.8.4 Mitigation Strategy The QA representative will maintain a list of functional specifications for regulatory compliance. These specifications are based upon the QA representative s knowledge of the proposed CROMERRR and the Part 11 regulations, and experience with the implementation of those regulations. These specifications will be included in the System Requirements Specification. 3.8.5 Contingency Plan This risk will only materialize if an auditor alleges that one or more of the compliance specifications was implemented in a non-compliant manner. If this risk were to materialize, the most appropriate course of action would be to remediate the noncompliant feature in a future upgrade project. Depending upon the nature of the noncompliance, it might be possible to implement short-term procedural controls to achieve compliance. 3.9 Unknown Defects or Incompatibility Among Prescribed Project Tools 3.9.1 Description Throughout the course of the project, several commercial and open-source software tools will be used to manage both the processes and the products. The potential exists for unknown defects in the tools, and for undiscovered incompatibilities among the tools. 3.9.2 Impact Unexpected delays as a result of errors introduced by defects or incompatibilities The need to replace a defective or incompatible software tool with an equivalent tool, and the subsequent migration of products to the new tool Extra time needed to learn a new tool 3.9.3 Indicators Defects and incompatibilities will not be apparent until such time as they are encountered during routine use. 3.9.4 Mitigation Strategy This risk has been mitigated by selecting a set of development tools that have been used successfully and have proven to be compatible on other TCC projects. Confidential Sample Company Page 19 of 22
3.9.5 Contingency Plan A backup and recovery plan has been defined that will provide the ability to rollback to previous versions of project artifacts. The Technical Lead will maintain a list of alternate development tools that can be used in the event that a critical incompatibility is discovered in the course of the project. In the event that an incompatibility results in the corruption of project artifacts, the backup will be used to restore uncorrupted versions of the artifacts. The incompatible tool will be replaced with one of the alternative tools. 3.10 Instability of the Operating System (OS) 3.10.1 Description The OS, layered products, packaged apps, and proprietary apps that have been selected for the project are known to be compatible. However, upgrades, patches, etc., that are applied to the development and test environments in the course of the project could cause unexpected compatibility issues and problems. 3.10.2 Impact System downtime Substantial schedule over-runs 3.10.3 Indicators New defects in software builds that were stable in previous configurations Server outages due to OS or layered product problems 3.10.4 Mitigation Strategy When feasible, review the release notes for patches and upgrades prior to installation to evaluate their potential for compatibility issues. Ensure that back-out procedures are in place for all software updates to production servers. Maintain regular backups of the development and testing servers to allow for the ability to roll back to previous versions of software. 3.10.5 Contingency Plan Roll back the server to a previously working state Install patches and updates as appropriate to regain compatibility Confidential Sample Company Page 20 of 22
3.11 Lack Organizational Control Over Security of Company-Confidential Information 3.11.1 Description 3.11.2 Impact Although confidentiality agreements will be secured for all contractors associated with the project, no reliable internal mechanisms exist for assuring that these agreements are observed, or for controlling unauthorized distribution of confidential data once it is made available to external agents. The impact resulting from the realization of this risk is largely dependent upon the nature of the compromised data. 3.11.3 Indicators No practical indicators can be identified to provide an early warning that this risk might materialize. Consequently, the technical team believes that the mitigation strategies for this risk should be seriously considered and consistently enforced. 3.11.4 Mitigation Strategy Identify and classify highly confidential company data and minimize the extent to which it is shared with external agents. Assign Monsanto employees to development tasks that require access to highly confidential company data. 3.11.5 Contingency Plan Any indication that third-party agents have compromised confidential company data immediately will be escalated to the Project Management Office and to the Project Directors. Confidential Sample Company Page 21 of 22
Attachment A - Risk Assessment Criteria The risks identified in this initial assessment were categorized and assessed from two perspectives, the likelihood that: The risk will occur The severity of its impact, should it occur The resulting list of project risks factors in Table 1 - Risk Assessment was assessed, using the table below as a reference, to arrive at a Risk Exposure score for each risk identified. PROBABILITY Impact Highly Likely Probable Improbable Catastrophic 6 (High) 5 (High) 4 (High) Critical 5 (High) 4 (High) 3 (Medium) Marginal 4 (High) 3 (Medium) 2 (Low) Negligible 3 (Medium) 2 (Low) 1 (Low) Table 2 - Risk Exposure Score The probability that a risk could materialize was assessed according to the following criteria: Highly Likely 90% or greater chance that the risk will materialize Probable 50 to 89% chance that the risk will materialize Improbable less than 50% chance that the risk will materialize The impact of a materialized risk was assessed according to the following criteria: Catastrophic Results in a failure to deliver the final product Critical Results in a material impact on the terms of the Project Contract Marginal Results in an undesirable but acceptable impact on the terms of the Project Contract Negligible Results in no significant impact on the terms of the Project Contract. Confidential Sample Company Page 22 of 22