Controlled Document Procedure

Purpose

Vaxa deploys control activities through policies and standards that establish what is expected and procedures that put policies and standards into action.

The purpose of this procedure is to ensure that there is consistency in developing and maintaining controlled documents at Vaxa utilizing a hierarchal approach for managing legal and regulatory requirements.

There are two types of documentation at Vaxa:

1. Controlled Documents: Formal policies, standards and procedures.
2. Uncontrolled Documents: Informal runbooks, certain handbook pages, guidelines, blog posts, templates, etc.

Everyone at Vaxa is welcomed and encouraged to submit a pull request to create or suggest changes to controlled documents at any time.

Scope

This procedure applies to all controlled documents developed in support of Vaxa’s statutory, regulatory and contractual requirements.

Uncontrolled documents are dynamic in nature and not in scope of this procedure.

Roles & Responsibilities

Procedure

Definitions by Hierarchy

Footnote: _{https://docs.google.com/presentation/d/125LxBkIx0gj42Ooky8hcx9HY2GEjfomDRdR_o-qbOpc/edit#slide=id.g1234fd827e0_0_0}

• Policy: A policy is a high-level statement of intent and defines Vaxa’s goals, objectives and culture. Statutory, regulatory, or contractual obligations are commonly the root cause for a policy’s existence. Policies are designed to be centrally managed at the organizational level (e.g. Security Compliance Team or Legal & Ethics Compliance Team).
• Standard: Standards are mandatory actions or rules that give formal policies support and direction by providing specific details that enable policies to be implemented. Standards may take the form of technical diagrams.
• Procedure: Procedures are detailed instructions to achieve a given policy and, if applicable, supporting standard and provid step-by-step instructions to follow. Procedures are decentralized and managed by process/control owners where a security control is translated into a business process.

Creation

At minimum, controlled documents should cover the following key topic areas:

• Purpose: Overview of why the controlled document is being implemented.
• Scope: Who or what does the controlled document apply to.
• Roles & Responsibilities: Who is responsible for doing what. This should refer to departments or roles instead of specific individuals.
• Policy Statements, Standard or Procedure: The details.
• Exceptions: Define how exceptions to the controlled document will be tracked.
• Compliance & Monitoring: Define how compliance with the controlled document will be monitored and what checks will be performed (where applicable).
• References: Procedure documents should map back to a governing policy or standard, and may relate to one or more procedures or other uncontrolled documentation. Policy documents may relate to an internal or external framework or legal requirement.

Publishing

Creation of, or changes to, controlled documents must be approved by management or a formally designated representative of the owning department as defined in the CODEOWNERS file prior to publishing.

Handbook header

Controlled documents require a handbook frontmatter attribute for controlled documents to classify them. This attribute also renders a warning header.

Review

Controlled documents are required to be reviewed and approved on at least an annual basis. Controlled documents may be updated ad-hoc as required by business operations. Changes must be approved by a code owner of the controlled document prior to merge.

Reviewers of controlled documents are required to

1. Ensure that “say why not just what” transparency is easily understood in the description. The title should be concise but clear on the what.
2. Ensure that announcements for team members are scheduled, and tick off the MR template task.

List of Controlled Documents

An accurate list of current controlled documents can be found here.

Exceptions

Exceptions to controlled documents must be tracked and approved by the controlled document approver(s) via an auditable format. An exception process should be defined in each controlled document.

In the event a team member requires a deviation from the standard course of business or otherwise allowed by policy, the Requestor must submit a Policy Exception Request to the Vaxa Security Compliance team, which contains, at a minimum, the following elements:

• Team member Name and contact
• Time period for the exception (deviations should not exceed 90 days unless the exception is related to a device exception, like using a Windows device)
• The exception being requested, i.e. which policy or procedure is affected by the proposed deviation
• Additional details as required by each template, to include evidence of security protections.

Exception request approval requirements are documented within the issue template. The requester should tag the appropriate individuals who are required to provide an approval per the approval matrix.

If the business wants to appeal an approval decision, such appeal will be sent to Legal at legal@Vaxa.com. Legal will draft an opinion as to the proposed risks to the company if the deviation were to be granted. Legal’s opinion will be forwarded to the CEO and CFO for final disposition.

Any deviation approval must:

• Recommended compensating controls to reduce exposure and/or harm (i.e. admin rights to financially significant system may require audit logs and review of users activity within the system)
• Be captured in writing

References