Evidence repository application system and method

An evidence repository application system provides a centralized repository of implementation evidence data for a project and to provide a method for collecting, storing and tracking the implementation evidence data for the project. The evidence repository application system receives and stores evaluation data regarding the implementation evidence data. The evidence repository application system generates interactive reports summarizing the evaluation data for a project. The evidence repository application system implements a consistent approval process for a project with identified accountable managers and evidence providers. The evidence repository application system also implements an accountability process that notifies accountable managers and evidence providers of their roles and responsibilities for a project.

CROSS-REFERENCE TO RELATED PATENTS

Not applicable.

Not applicable.

Not applicable.

BACKGROUND OF THE INVENTION

1. Technical Field of the Invention

This invention relates to data management and in particular to a project data management system and method.

2. Description of Related Art

When an organization implements a policy, a process or a system, the organization often needs to verify implementation of the policy, demonstrate implementation of the process, or validate usage of the system. However, there are currently various problems with providing the evidence necessary to verify such implementation. One existing problem is that the necessary evidence may be widely dispersed throughout the organization and difficult to locate. Furthermore, if located, the necessary evidence may not be inventoried or stored in an accessible manner. For example, a risk management group in an organization may need to verify implementation of a corporate control policy but are unable to locate and organize fact-based evidence of implementation. As another example, an accounting group may need to attest to regulatory compliance but do not have the necessary documentation of implementation of procedures. As yet another example, an information technology group may need to demonstrate security testing status of a worldwide set of systems without a fully documented inventory.

Another problem in verifying implementation of a policy, a process or a system is that the management of an organization may have little knowledge of the relative completeness or strength of the evidence underlying the verification. For example, the management may unknowingly attest to claims of compliance for a policy with unsubstantiated evidence, such as verbal assurance, rather than any fact-based documented evidence. In addition, a claim by management of global compliance with a corporate control may unknowingly be based on documented evidence only provided by some but not all business units.

Another problem is that approval methods for a policy, a process or a system often lack definitive personnel accountability, clear and repeatable methodology, and documented tracking of activities and changes. Across an organization, there may be various policy, process and system implementation and approval processes where: the personnel accountabilities are unclear, unconfirmed and undocumented; methodologies are fluid and informal; and the activities and revisions are undocumented and untracked. This type of disorganization results in extra time, inconsistent processes and arbitrary basis for approvals.

As such, a need exists for a system and methodology for managing, tracking, rating and approving implementation evidence of a policy, a process or a system.

DETAILED DESCRIPTION OF THE INVENTION

In accordance with an embodiment of the invention, an evidence repository application system is operable to provide a centralized repository of implementation evidence data for a project and to provide a method for collecting, storing and tracking the implementation evidence data for the project. In accordance with an embodiment of the invention, the evidence repository application system is operable to generate project reports and manage approval process for the project. These and other functions of the evidence repository application system in accordance with embodiments of the invention are described herein.

FIG. 1is a schematic block diagram of an embodiment of a network system10in which the evidence repository application (ERA) system20may be implemented in accordance with the present invention. The network system10includes one or more networks, such as wide area network (WAN)12and local area networks (LAN)14,16that are operable to communicate with the system20. A plurality of devices18are connected to the WAN12, the LAN14and LAN16. Some of the devices18may be connected via a wireless LAN modem22, a cellular network or other type of wireless network (not shown). The devices18include a personal computer, a laptop, a wireless phone, a personal digital assistant or other device operable to communicate over the WAN12, LAN14or LAN16with the system20.

The system20includes an interface module24, an application module26and a repository database28. The interface module24is operable to interface with the plurality of devices18over the LAN16, the WAN12, and/or the LAN14. In an embodiment, the interface module24includes a network card, a web or file server that is operable to communicate using the Hyper Text Transfer Protocol (HTTP) protocol, File Transfer Protocol (FTP) or other protocol operable to communicate data, such as Hypertext Markup Language (HTML) documents, text, images, audio, videos or other types of data. The interface module24may also include a firewall or authentication capability that requires password or other authentication data prior to allowing access to some or all of the resources of the system20. The interface module24may also include gateway, proxy server functions or modems, network terminals or other hardware or software devices that are operable to provide communication between the system20and the devices18.

In an embodiment, the application module26is a server with a processing module30operable to perform functions described herein. In general, the processing module30may be a single processing device or a plurality of processing devices. Such a processing device may be a microprocessor, micro-controller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that manipulates signals (analog and/or digital) based on hard coding of the circuitry and/or operational instructions. The processing module30includes a memory that is an internal memory or an external memory. The memory of the processing module30may each be a single memory device or a plurality of memory devices. Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information. Note that when the processing module implements one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory storing the corresponding operational instructions may be embedded within, or external to, the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry. Further note that, processing module may execute hard coded and/or operational instructions stored by the internal memory and/or external memory to perform the steps and/or functions illustrated inFIGS. 1 through 18described with respect to the application module26. The application module26and the interface module24may be integrated into one or more devices or may be separate devices.

The system20also includes a repository database28. The repository database28may be one or more databases implemented in internal memory devices, detached memory devices, network attached storage devices, storage area networks, or other storage devices located in one geographical location or multiple geographical locations. The repository database28may be structured as relational, network, hierarchal or object based or other type of structured database or document management application operable to store and locate data files. The repository database28is operable to communicate with the interface module24and the application module26.

FIG. 2illustrates the system20, a compliance manager device30, a compliance officer device32, a project owner device34, and an evidence provider device36. Each of the devices30,32,34,36may be any of the devices18described with respect toFIG. 1. In use, the compliance manager device30transmits and the system20receives a project definition38. The project definition38includes a project name, a year, and a summary description of the project. In addition, the project definition38includes one or more identities (e.g., e-mail address, network address, cell phone number, computer identification code, etc.) for accountable managers for the project. The accountable managers are one or more persons, positions or entities that are responsible for workflow or approval process for the project. For example, the accountable managers for a project may include a compliance manager, a compliance officer and a project owner. Though certain roles and responsibilities are described herein for the accountable managers, these roles and responsibilities may be assigned to one or more other accountable managers or other roles and responsibilities may be assigned to one or more of the accountable managers. In addition, though three accountable managers are described herein, less or more than three accountable managers may be assigned and more than one identity may be assigned for an accountable manager. For example, though one identity of a compliance manager may be assigned to a project in the embodiment of the invention inFIG. 2, in another embodiment, two identities for a compliance manager may be assigned to a project or the roles of compliance manager and compliance officer may be assigned to a single identity.

The project definition38further includes a plurality of requirements for the project and one or more types of implementation evidence data acceptable for one or more of the plurality of requirements. In this instance, the project definition38further includes one or more identities of an evidence provider. The identity of an evidence provider is assigned to a requirement to collect and transmit the type of implementation evidence data acceptable to the requirement. The evidence provider identity may be one or more names, positions, e-mail addresses, network address, computer identification code, cell phone number, or other identifying information. The system20processes the received project definition38and stores the data in the repository database28to create a project.

As explained in more detail below with respect toFIGS. 6 and 7, a notification of accountability including a type of acceptable evidence is transmitted from the system20to the evidence provider device. When the evidence provider accepts the notification of accountability, the evidence provider device36transmits implementation evidence data40to the system20in accordance with the type of acceptable evidence. The implementation evidence data40is data that demonstrates implementation of a requirement for the project, including data files, such as documents, spreadsheets, presentations, surveys, opinions, video, photos, audio type files or references, links, or other types of information. The compliance manager device transmits and the system20receives evaluation data42relating to the implementation evidence data40. The evaluation data42includes data evaluating the implementation evidence data40, such as completeness percentage, surety level or other criteria. The system20generates an evidence dashboard44for a project which summarizes the evaluation data42relating to the implementation evidence data40through one or more interactive reports. The compliance manager device30may access the system20to view the evidence dashboard44and to review the evaluation data42relating to the implementation evidence data40.

The compliance manager device30may then transmit a request for validation46which is received by the system20. The request for validation46is a request for validation that the implementation evidence data32for at least one requirement of a project is accurate, current and complete. For example, the request for validation46may include a request for validation that the implementation evidence data32for one requirement, more than one requirement or all the requirements of a project is accurate, current and complete. In response to receiving the request for validation46, a validation request48is generated by the system20and is transmitted to the compliance officer device32. The compliance officer device32may also access and display the evidence dashboard44to review the evaluation data42relating to the implementation evidence data40. The system20then receives a validation50of the implementation evidence data40for the at least one requirement of the project from the compliance officer device32.

The system20may then receive a request for attestation52for the project from the compliance officer device32. The request for attestation52is a request for attestation that the implementation evidence data40for a project is accurate, current or complete. The request for attestation52may also include that the implementation evidence data40is sufficient to satisfy compliance with or implementation of the project. The system20receives the request for attestation52and generates an attestation request54for the project. In an embodiment, the system20transmits the attestation request54to the project owner device34. The project owner device34may also access and display the evidence dashboard44. The system20then receives an attestation56from the project owner device34that the implementation evidence data for a project is accurate, current or complete. The system20may also receive an attestation56from the project owner device34that the implementation evidence data40is sufficient to ensure compliance with the project or to show implementation of the project. Alternatively, the system20may receive from the project owner device34a customized attestation56or an attestation56with one or more exceptions. The system20receives the attestation56for the project from the project owner device34and stores the attestation56in the repository database28.

The system20thus provides a centralized repository for implementation evidence data40of a project. In addition, by accessing the evidence dashboard44generated by the system20, accountable managers may more easily assess the implementation evidence data40using the evaluation data42before validating or attesting to the implementation evidence data40. In addition, the system20implements a consistent approval process for a project with identified accountable managers and evidence providers.

FIG. 3is a logic flow diagram of an embodiment of a method for project creation58by the system20in accordance with the present invention. In step60, the system20receives a selection of a program. A program may include projects that apply to a geographical area of a corporation or projects for a corporate department or projects relating to a corporate effort such as, corporate merger or corporate relocation. For example, a Company Region1program may include projects applicable to the entire Region1of the Company or for different departments in Region1. An Accounts Payable program may include projects that apply to the global Accounts Payable department or projects that apply to different geographical areas. A corporate merger program may include projects required to implement the integration of two companies across various corporate departments. In step62, a project definition38is received by the system20to create a project under the selected program. A project under the selected program comprises a policy, a process, a system (e.g., hardware, software, networking, security, system usage) or a standard for which data needs to be collected, stored and tracked. For example, a project may include providing evidence of implementation of compliance with a corporate policy or showing implementation of a process or tracking migration to a new hardware or software application or integration of information technology (IT) resources of two companies during a merger. The project definition38received by the system20includes information for the system20to create the project, such as the information described below with respect to steps64through74.

In step64, a project name and year for the project is received by the system20. By specifying the year for the project, a continuous project that needs constant updating, such as compliance with a corporate policy, may be tracked year by year. In step66, the system20receives one or more identities of accountable managers for the project and stores the identities in the repository database28with respect to the project. In an embodiment, the accountable managers for a project include a compliance manager, compliance officer and project owner. An identity for an accountable manager may include one or more names, positions, e-mail addresses, network address, computer identification code, cell phone number, or other identifying information. In step68, the system20receives and stores a project summary description, which may include descriptions of the overall goals and purpose of the project.

In step70, the system20receives and stores a plurality of requirements for the project. A requirement for a project is a step, milestone, action, policy or other information needed for the project. In step72, the system20receives one or more acceptable types of implementation evidence data for each requirement. A type of implementation evidence data is a description of acceptable evidence for a requirement. For example, a type of implementation evidence data may specify a survey, an account spreadsheet, a training presentation, attendance of the training presentation, testimony, video, or other type of data. For example, a project may comprise tracking migration to a new software application, and one of the plurality of requirements may be attendance by application users at a training session for the software application. The types of implementation evidence data for the requirement may include a copy of a presentation for the training session, attendance records for the training sessions, evaluations of the training session by attendees, etc. In step74, the system20receives identities (e.g., e-mail address, network address, cell phone number, computer identification code, etc.) of evidence providers. The evidence providers are assigned to collect and transmit implementation evidence data40to the system20for the requirements. An evidence provider may be assigned to each requirement or multiple evidence providers may be assigned to one requirement or the same evidence provider may be assigned to multiple requirements of the project. In step76, the system20processes and stores the received project definition38and creates the project.

FIG. 4is a logic flow diagram of an embodiment of a method80for processing implementation evidence data40and evaluation data42by the evidence repository application system20in accordance with the present invention. Once the project has been created in the system20, then implementation evidence data40may be collected and entered into the system20. In step82, the system receives implementation evidence data40for at least one requirement of a plurality of requirements of a project. In an embodiment, the implementation evidence data40received for the at least one requirement is in accordance with the type of implementation evidence data desired for the requirement. In some instances, the type of implementation evidence data is the same for more than one requirement, and so the same piece of implementation evidence data may satisfy more than one requirement. In this case, the implementation evidence data does not need to be uploaded to the system20multiple times. Instead, the implementation evidence data is transmitted and uploaded for at least one of the requirements and a cross reference to the implementation evidence data is made in other requirements. In some instances, the type of implementation evidence data requested in the project definition is not attainable due to availability, cost, timing or other issues. Evidence provider and accountable managers may need to negotiate and agree on another type of implementation evidence data for the requirement. The system20is then updated with the modified type of implementation evidence data for the requirement. In step84, the system20stores the implementation evidence data40in the repository database28.

In step86, the system20receives evaluation data42relating to the implementation evidence data40for the at least one requirement of the project. In step88, the system20stores the evaluation data42in the repository database28. In an embodiment, the evaluation data42received by the system20includes a percentage of completeness of the implementation evidence data40for the at least one requirement of the project and a surety level of the implementation evidence data. The surety level provides a measure of strength or a degree of reliability of the implementation evidence data40. For example, the system20supports entry of three surety levels: (S1) Self-assessment, (S2) Some factual documentation, and (S3) Full Factual Documentation. For instance, for the requirement of attendance by application users at a training session for a new software application, one of the types of implementation evidence data for the requirement may be attendance records for the training sessions. If the attendance records are based on self-assessment, such as verbal promises of attendance, then a surety level of S1may be assigned. If the attendance records are based on unmonitored sign-up sheets at a training session, then a surety level of S2may be assigned. If the attendance records are prepared by the trainers at the training session by checking identification of attendees before and after the training sessions, then a surety level of S3may be assigned. In addition, with respect to the percentage of completeness of the implementation evidence data40, if the attendance records indicate that 80% of the required application users have attended the training sessions, then the percentage of completeness may be assigned at 80%. Thus, evaluation data relating to the implementation evidence data40of attendance at a training session may have a surety level of S3but only a percentage of completeness of 80%. The evaluation data42may include other criteria for assessing the implementation evidence data40, such as a currency rating indicating the relative currency of the implementation evidence data40. For example, an average time since attendance of the training sessions by the required application users may be determined, and a currency rating assigned depending on the average time, e.g a higher currency rating for an average within three months than 6 months or 12 months. Other types of evaluation data may be received and processed by the system20as well.

FIG. 5illustrates a schematic block diagram of an embodiment of the repository database28of the system20in accordance with the present invention. The repository database28may be structured as relational, network, hierarchal or object based or other type of structured database or document management application operable to store or manage data files. The repository database28stores one or more programs100and one or more projects102associated with a program100. The repository database28stores a plurality of requirements104for a project102. The repository database28stores one or more types of implementation evidence data106for a requirement104. A type of implementation evidence data106may not be stored for a requirement104when no evidence is needed for the requirement. One or more pieces of implementation evidence data40are stored for a type of implementation evidence40. Evaluation data42relating to the implementation evidence data40is also stored in the repository database28. The evaluation data42includes data evaluating the implementation evidence data40, such as a completeness percentage108, a surety level110, a currency rating112or other criteria114. The evaluation data42may relate to one piece of implementation evidence data40or to multiple pieces of implementation evidence data40for a requirement. For example, implementation evidence data40for the training sessions may include multiple attendance records. The evaluation data42would then relate to the multiple attendance records. However, if the implementation evidence data40is a training presentation, the evaluation data42may then relate only to that piece of implementation evidence data40.

FIG. 6is a logic flow diagram of an embodiment of a method120for processing acceptance of accountability by the system20in accordance with the present invention. In step122, the system20receives an identity of an evidence provider or an identity of an accountable manager, such as an identity of a compliance manager, a compliance officer or a project owner. In step124, the system20provides a first status indication that no accountability notice has been generated for the identified evidence provider or accountable manager. In step126, the system20generates and transmits a notification of accountability to the evidence provider/accountable manager. The system20may receive a request that a notification of accountability be transmitted or the system may automatically generate the notice of accountability. The system20may also generate multiple notices of accountability and transmit a notification of accountability to each identified evidence provider devices in a batch. In an embodiment, a notification of accountability to an identified accountable manager device is transmitted individually to avoid multiple notices to an accountable manager. However, in another embodiment, notice of accountability may be transmitted to the accountable manager devices for a project in a batch.

In step128inFIG. 6, the system20generates a second status indication that a notice of accountability has been transmitted to an evidence provider device or accountable manager device. In step130, the system20receives a response to the notice of accountability from the evidence provider device or accountable manager device. In step132, the system determines whether the evidence provider/accountable manager accepted the notice of accountability. In step134, when the evidence provider/accountable manager refused acceptance of accountability, the system20provides a third status indication that accountability was not accepted by the evidence provider/accountable manager. In step135, when the evidence provider/accountable manager accepted accountability, the system20provides a fourth status indication that accountability was accepted by the evidence provider/accountable manager.

FIG. 7is a schematic block diagram of an embodiment of a graphical user interface (GUI) for displaying status of accountability138by the evidence repository application system20in accordance with the present invention. The display140for displaying the statue of accountability138may include any type of display for a device18. The status of accountability138includes one or more status indications142, one or more identities of accountable managers144, and one or more identities of evidence providers154. The status indications142for the identified accountable managers144and identified evidence providers154include: a first status indication146that no accountability notice has been generated for the identified evidence provider154or accountable manager144; a second status indication148that a notice of accountability has been transmitted to the identified evidence provider154or accountable manager144: a third status indication150that accountability was not accepted by the identified evidence provider154or identified accountable manager144; and a fourth status indication152that accountability was accepted by the identified evidence provider154or identified accountable manager144. Though the status indications142shown inFIG. 7include symbols, other status indications142may be implemented in an embodiment of the invention, such as words, colors, video graphics, sounds, etc.

The process of acceptance of accountability120shown inFIGS. 6 and 7provides a consistent process to notify accountable managers144and evidence providers154of their roles and responsibilities for a project102. In addition, the status indications142provide an efficient method for assessing acceptance or rejection of the notice of accountability by an identified accountable manager144or identified evidence provider154. As such, the identities of the accountable managers144and evidence providers154can be verified for the project because each identified accountable manager144and identified evidence provider154has been informed of their accountability with respect to the project and accepted the accountability. The system20thus implements an efficient method of acceptance of accountability120for notifying each identified accountable manager144and evidence provider154of their accountabilities, obtaining consent to accountability and providing status indications142of accountability.

FIGS. 8 through 14illustrate an embodiment of the process for system20to provide an evidence dashboard44. The system20generates an evidence dashboard44for a project102which summarizes the evaluation data42relating to the implementation evidence data40through one or more interactive reports. The evidence dashboard44may be accessed to review the evaluation data42relating to the implementation evidence data40by an accountable manager.

FIG. 8is a schematic block diagram of an embodiment of a graphical user interface (GUI) of a program display160generated by the system20in accordance with the present invention. The program display160includes a display or listing of one or more programs100. The listing of programs100may be shown in a drop down menu or other manner. Each of the displayed programs100may be selected in the graphical user interface to request a program report164as shown inFIG. 9.

FIG. 9is a schematic block diagram of an embodiment of a graphical user interface of a program report164generated by the system20, in accordance with the present invention. The program report164displays one or more projects102that are part of the selected program100. The program report164also summarizes evaluation data42for the one or more projects102in the program100. In the example ofFIG. 9, the percentage of completeness108of the implementation evidence data40for the projects102is summarized by a bar graph. Other evaluation data42may be summarized as part of the program report164using other types of graphs or charts. For example, a surety level110may be displayed for each project102in a graph rather than the percentage of completeness108. The program report164may include a chart that displays a currency rating112and the percentage of completeness108of the evaluation data for each project102. The program report164may also include a year selection166to select the year for the projects100in the program report164. Each of the projects102may be selected in the graphical user interface of the program report164to request a project report168for the selected project102as shown inFIG. 10.

FIG. 10is a schematic block diagram of an embodiment of a graphical user interface of a project report168by the system20in accordance with the present invention. The project report168summarizes evaluation data for a plurality of requirements104for the selected project102. In an embodiment shown inFIG. 10, the project report168includes a number170of each requirement104, each requirement104, evaluation data42for each requirement104, and a view detail selection icon174for each requirement104. The evaluation data42displayed for each requirement104may be the percentage of completeness108. Alternatively, or in addition to, the evaluation data42may be displayed for each of the plurality of requirements104in the project report168. Each of the plurality of requirements104may be selected in the graphical user interface of the project report168to request a requirements report180for the selected requirement104as shown inFIG. 11.

FIG. 11is a schematic block diagram of an embodiment of a graphical user interface of a requirements report180generated by the system20, in accordance with the present invention. The requirements report180summarizes the evaluation data42relating to the implementation evidence data40for the selected requirement104. For instance, the requirements report180includes the type of implementation evidence data106desired for the selected requirement104. The requirements report180also includes evaluation data42and an identity of an evidence provider154for each type of implementation evidence data106. Each of the plurality of types of implementation evidence data106may be selected in the graphical user interface of the requirements report180to request an implementation evidence data report190for the selected type of implementation evidence data106as shown inFIG. 12.

FIG. 12is a schematic block diagram of an embodiment of a graphical user interface of an implementation evidence data report190by the system20in accordance with the present invention. The implementation evidence data report190lists the implementation evidence data40stored by the system20for the selected type of implementation evidence data106for the selected requirement104. For instance, the implementation evidence data report190includes a description192of the implementation evidence data104and evaluation data42for the implementation evidence data104. The evaluation data42of the implementation evidence data104includes a percentage of completeness108and a surety level110. The implementation evidence data report190also includes a list of the implementation evidence data40stored by the system20. One of the implementation evidence data40may be selected in the graphical user interface of the implementation evidence data report190to request the implementation evidence data40as shown inFIG. 13.

FIG. 13is schematic block diagram of an embodiment of a graphical user interface of the selected implementation evidence data40stored by the evidence repository application system20in accordance with the present invention. The system20displays the selected implementation evidence data40.

FIG. 14is a logic flow diagram of an embodiment of a method200for generating the evidence dashboard44by the system20in accordance with the present invention. In step202, the system20receives a request for a program display110. In step204, the system20generates a graphical user interface (GUI) of an interactive program display110that lists a plurality of programs100. In step206, the system20receives a selection of one of the programs100in the program display110. In step208, the system20generates a GUI of an interactive program report164that summarizes the evaluation data42for a plurality of projects102in the program100. In step210, the system20receives a request for a project report168for one of the plurality of projects102in the program. In step212, the system20generates an interactive project report168that summarizes the evaluation data42relating to implementation evidence data40for a plurality of requirements104of the project102. In step214, the system20receives a request for a requirements report180for at least one requirement of the plurality of requirements104of the project102. In step216, the system20generates a GUI of the requirements report180that summarizes the evaluation data42relating to the implementation evidence data40for the at least one requirement104of the plurality of requirements. In step218, the system20receives a request for an implementation evidence data report190for the at least one requirement104of the plurality of requirements. In step220, the system20generates a GUI of the implementation evidence data report190that lists the implementation evidence data40stored by the system20for the at least one requirement104of the plurality of requirements. In step222, the system20receives a request to access one of the listed implementation evidence data40for the at least one requirement104. In step224, the system20generates a GUI of the requested implementation evidence data40for the at least one requirement104.

In an embodiment, the system20generates the evidence dashboard44of interactive reports for one or more projects102as described with respect toFIGS. 8 through 14. The evidence dashboard44may be accessed to review the evaluation data42relating to the implementation evidence data40. As such, accountable managers may better assess whether the implementation evidence data40for a project is accurate, current or complete prior to validating or attesting to the implementation evidence data40for a project. In addition, accountable managers are able to more easily determine from the evaluation data42whether implementation evidence data40is insufficient for a requirement or additional implementation evidence data is desired for a requirement. When additional implementation evidence data is desired for a requirement, the system20provides a method for creating a remediation plan for the requirement.

FIG. 15is a logic flow diagram of an embodiment of a method240for creating a remediation plan by the system20in accordance with the present invention. In step242, the system20receives a request to create a remediation plan for a requirement104, wherein additional implementation evidence data40is desired for the requirement104. In step244, the system20receives and stores a milestone for the remediation plan. In step246, the system20receives and stores a description of the milestone, a start date and a completion date for the milestone. The system20also receives a percentage of effort to complete a milestone in relation to the total effort to complete the remediation plan. For example, the percentage of effort to complete a milestone may consist of 20% of the 100% total effort to complete the remediation plan.

In step248ofFIG. 15, the system20determines whether another milestone is desired for the remediation plan. When another milestone is desired, the system20returns to step244to receive and store the next milestone for the remediation plan. In an embodiment, when another milestone is not desired, the system20proceeds to step250to automatically create a milestone to provide documentation for the remediation plan and sets the percentage of effort at 10%. In step252, the system20sums the percentages of effort for each milestone in the remediation plan. In step254, the system20may provide notifications of key dates in the remediation plan, such as start and completion dates of milestones. For example, one type of notification may include a reminder notice in the form of one or more emails to the compliance manager or other accountable manager for the project that a milestone completion date is approaching within a time frame.

FIG. 16is a logic flow diagram of an embodiment of a method for an approval process260of a project102by the system20in accordance with the present invention. In an embodiment, the system20implements a consistent approval process for a project102with identified accountable managers. In step262, the system20receives a request for validation46of implementation evidence data40for a project102from a first accountable manager. In step264, the system20transmits a validation request48to a second accountable manager and in step266, receives a validation50of the implementation evidence data for the project102from the second accountable manager. In step268, the system20receives a request for attestation52for the project102from the second accountable manager. In step270, the system20transmits an attestation request54to a third accountable manager. In step272, the system20receives an attestation56of the project102from the third accountable manager. In step274, the system20stores the attestation56of the project102in the repository database28and provides an indication of the attestation56of the project102.

The system20also includes various security features. In an embodiment, the security features of the system20include one or more change logs that track changes to data in the system20.

FIG. 17is a schematic block diagram of an embodiment of a graphical user interface of a log of changes282generated by the system20, in accordance with the present invention. The log of changes282includes a selection for a project102and a year selection284for the project102. The log of changes282then displays changes to data for the selected project102for the selected year284.

The log of changes282includes a date286in which a change was made to data for the project102and the change type288. The change type288describes a general category of the data or type of change made in the system20. For example, the change type288may include policy edit, data upload, remediation milestone added, project creation, etc. The log of changes282also includes a change description290which provides a more detailed description of the change. For example, the change description290may state, “compliance manager identity changed from X to Y” or “remediation milestone added to remediation plan for Requirement 2.1”. The log of changes282also includes an identity292of a person who made the change to the data of the project102. Other information may be included in the log of changes282or other change logs may also be implemented.

FIG. 18is a logic flow diagram of an embodiment of a method for access restrictions300by the system20in accordance with the present invention. The method for access restrictions300provides another security feature for system20for limiting the access and use of the data in the system20. In step302, the system20receives a set of permissions for access and use of the system20. The set of permissions in an embodiment include view evidence dashboard44, view attestations56, view projects102, create a project102, edit a project definition38, upload implementation evidence data40or evaluation data42, view change logs and create a program100. Other functions or data of the system20may also be included in the set of permissions. In addition, the set of permissions may be restricted to a particular project or program or requirement. In step304ofFIG. 18, the system20then receives assignment of one or more permissions from the set of permissions for a user of the system20. For example, an accountable manager144may be assigned permissions from the set of permissions to edit a project definition38, view change logs, and view projects. An evidence provider154may be assigned permissions from the set of permissions to upload implementation evidence data40or evaluation data42but only for a particular requirement104for a particular project102. In step306, the system20grants access and use of the system20to a user in accordance with the assignment of permissions to the user.

As may be used herein, the term “operable to” indicates that an item includes one or more of processing modules, data, input(s), output(s), etc., to perform one or more of the described or necessary corresponding functions and may further include inferred coupling to one or more other items to perform the described or necessary corresponding functions.