July 10, 2014 | Posted in GRC by Scott Byrum
When we discuss Archer with our clients, we commonly begin the discussion on their use cases for the tool. We usually hear about the core modules that the client has purchased such as risk, compliance, policy, audit, or business continuity management. This provides a general sense of what the client is interested in but general use cases like “risk management” can mean completely different things across organizations and industries.
We encourage customers to think in terms of specific objectives for Archer such as:
- Determine which “assets” (e.g. business units, apps, servers, facilities, vendors) are in scope for compliance requirements (e.g. PCI DSS, SOX, HIPAA)
- Facilitate an annual compliance assessment and track issues through remediation
- Document tasks that must be executed to recover an app or business process in the event of a disruption and present tasks to relevant personnel based on role
- Facilitate the internal vendor procurement process workflow including need recognition, vendor analysis, and contract execution
These objectives are more meaningful than the name of a core module and can serve as a baseline for establishing an appropriate licensing structure and ultimately to granular implementation requirements.
Archer is flexible enough to support most processes though in our experience, customization is required to get the most value out of the tool. Rather than thinking in terms of Archer’s out-of-the-box modules, identify more specific use case objectives and do the homework to determine the most effective way to configure Archer to meet your objectives. Following this approach can save licensing dollars, time and headaches associated with attempting to force existing processes into an out-of-the-box core module.
Contact me to discuss how we can help at firstname.lastname@example.org.