GRC-Importable Cybersecurity Policies & Standards   

At ComplianceForge, we take a unique view towards writing cybersecurity documentation. Contrary to the traditional “SANS model” of writing multiple standalone cybersecurity policy documents, we developed a comprehensive and scalable way to write cybersecurity documentation that minimizes redundancies and inefficiencies that plaque cybersecurity governance. This methodology is ideal for GRC platforms, since those are also structured to be hierarchical.

 

ComplianceForge believes that a standard is a standard for a reason. We provide direct references to industry-leading practices, so that clients can clearly see what requirements impact them, as well as filter requirements to their specific business requirements. This built-in mapping can be imported directly into your GRC instance.

Since a picture can be worth 1,000 words, the video to the right helps describe this methodology where you can see examples of the hierarchy structure and overall flow of our documentation.

   Digital Security Program (DSP)   

Test1.jpg

The Digital Security Program (DSP) is purpose-built for GRC implementations. 

  • Hierarchical policies, control objectives, standards, guidelines, controls & metrics!

  • Addresses both cybersecurity and compliance governance!

  • Mapping to over 100 statutory, regulatory and contractual frameworks!

  • Organized into 32 domains (each with its own policy and associated standards) to build a modern, "digital" cybersecurity & privacy program!

  • Importable format into your GRC instance (Microsoft Word and Excel)

When viewed in terms of a "cybersecurity spectrum," the comprehensive nature of the DSP puts it on the robust coverage side of this spectrum. The DSP leverages the Secure Controls Framework (SCF) as its core control set. 

2019 - spectrum - Cybersecurity Best Pra

The video to the right helps demonstrate how the DSP ties everything together to create a scalable, comprehensive cybersecurity & privacy governance program:

  • CONTROL OBJECTIVES exist to support POLICIES

  • STANDARDS are written to support CONTROL OBJECTIVES

  • PROCEDURES are written to implement the requirements that STANDARDS establish

  • CONTROLS exist as a mechanism to assess/audit both the existence of PROCEDURES / STANDARDS and how well their capabilities are implemented and/or functioning

  • METRICS exist as a way to measure the performance of CONTROLS