JupiterOne implements policies and procedures to maintain compliance and integrity of data. The Security Officer is responsible for maintaining policies and procedures and assuring all JupiterOne workforce members, business associates, customers, and partners adhere to all applicable policies.
Previous versions of policies are retained to assure ease of finding policies at specific historic dates in time.
JupiterOne policy requires that:
(a) JupiterOne policies must be developed and maintained to meet all applicable compliance requirements, such as SOC2 Security, and adhere to security best practices.
(b) All policies must be reviewed at least annually. PROG1
(c) All policy changes must be approved by JupiterOne Security Officer. Additionally,
(d) All policy documents must be maintained with version control, and previous versions must be retained for a minimum of seven years.
(e) Policy exceptions are handled on a case-by-case basis.
Policies are written in individual documents, each pertaining to a specific domain of concern.
Each document starts with the current version number in the format of
2017.1), followed by a brief summary. The remaining of the document is
structured to contain the following subsections:
Each JupiterOne policy document contains a version and optionally a revision number. The version number is the four digit year followed by a number, to indicate the year and sequence number of the policy at which time it was written or updated.
The version number shall be incremented by one with each material change to the
policy content. For example, if a new policy statement is added or a technical
control/procedure is updated to
2017.1 version of a policy, the new version
should be numbered
The policy document may also include a revision number, in the format of
rev.#, immediately following the main version number. A revision number
indicate minor, non-material changes to the document, such as formatting
changes, fixing typos, or adding minor details.
If sequencing numbers are included in the policy headings:
Policy may be referenced by its statement number, such as
internal/external communications as well as in other JupiterOne policies or
technical/business documentation for cross reference.
As such, to maintain cross referencing integrity, starting from version
2020.1, all numbering shall remain intact for policy documents and
When updating, avoid reordering and renumbering of policy documents and statements. For example:
All policies are stored and up to date to maintain JupiterOne compliance with all relevant and adopted standards. Updates and version control are done similar to source code control.
Policy update requests can be made by any workforce member at any time. Furthermore, all policies are reviewed annually by the Security Officer to assure they are accurate and up-to-date. PROG1
JupiterOne employees may request changes to policies using the following process:
The JupiterOne employee initiates a policy change request by creating an GitHub Pull Request (PR) from a new branch containing the desired changes.
The Security Officer is assigned to review the policy change request.
Once the review is completed, the Security Officer approves or rejects the PR. If the PR is rejected, it goes back for further review and documentation.
If the PR is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
If the policy change requires technical modifications to production systems, those changes are carried out by authorized personnel using JupiterOne’s change management process.
If the change results in a new version instead of a new revision (see definitions above), the current version of the policy document(s) must be saved to archive under the corresponding version number prior to the new policy being adopted/published and prior to merging the pull request containing the changes. This allows easy reference to previous versions if necessary.
* Changes are made on the `drafts` (or equivalent) branch instead of on the `master` branch for commits. * If multiple authors are working on the changes, additional separate branches and pull requests may be necessary before changes are merge in `drafts`. * Changes must not be merged to `master` without the approval of Security Officer. * Changes must not be merged to `master` without archiving the existing version of policy document(s), unless the change is a minor revision. * Once the changes are final and approved, a pull request shall be created from the `drafts` branch to the `master` branch and all members of the development team shall be included as approvers. This serves as communication and training of policy updates to the development organization, and the pull request approvals serve as records of training received. * Policy update communication and training for non-development staff is conducted separately by the Security team.
All policies are made accessible to all JupiterOne workforce members. The current master policies are published to JupiterOne and available at https://j1.apps.us.jupiterone.io/policies/.
All policies, and associated documentation, are retained for 7 years from the date of its creation or the date when it last was in effect, whichever is later
The policies and information security policies are reviewed and audited annually PROG1, or after significant changes occur to JupiterOne’s organizational environment, by the Security Committee members. Issues that come up as part of this process are reviewed by JupiterOne management to assure all risks and potential gaps are mitigated and/or fully addressed. The process for reviewing policies is outlined below:
Additional documentation related to maintenance of policies is outlined in Roles and Responsibilities.