{"id":13583130,"url":"https://github.com/JupiterOne/security-policy-templates","last_synced_at":"2025-04-06T18:31:54.258Z","repository":{"id":40562611,"uuid":"177619804","full_name":"JupiterOne/security-policy-templates","owner":"JupiterOne","description":"A set of policies, standards and control procedures with mapping to HIPAA, NIST CSF, PCI DSS, SOC2, FedRAMP, CIS Controls, and more.","archived":false,"fork":false,"pushed_at":"2024-06-18T20:10:42.000Z","size":2222,"stargazers_count":303,"open_issues_count":10,"forks_count":88,"subscribers_count":27,"default_branch":"main","last_synced_at":"2025-01-01T00:02:45.031Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"cc-by-sa-4.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/JupiterOne.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-03-25T16:02:44.000Z","updated_at":"2024-12-27T17:48:25.000Z","dependencies_parsed_at":"2024-01-02T20:26:56.088Z","dependency_job_id":"9bf86174-90d7-4b5f-9f3f-7ef583572eb5","html_url":"https://github.com/JupiterOne/security-policy-templates","commit_stats":{"total_commits":214,"total_committers":39,"mean_commits":5.487179487179487,"dds":0.6962616822429907,"last_synced_commit":"0dcc3b23ebf582254962c13df14b570c27c36a37"},"previous_names":[],"tags_count":21,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JupiterOne%2Fsecurity-policy-templates","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JupiterOne%2Fsecurity-policy-templates/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JupiterOne%2Fsecurity-policy-templates/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/JupiterOne%2Fsecurity-policy-templates/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/JupiterOne","download_url":"https://codeload.github.com/JupiterOne/security-policy-templates/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247142062,"owners_count":20890652,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T15:03:16.414Z","updated_at":"2025-04-06T18:31:52.890Z","avatar_url":"https://github.com/JupiterOne.png","language":"JavaScript","funding_links":[],"categories":["JavaScript"],"sub_categories":[],"readme":"# security-policy-templates\n\nA set of foundational but comprehensive policies, standards and procedures\ndesigned for cloud-native technology organizations. The policy package covers\nthe requirements and controls for most compliance frameworks and best practices,\nin a lightweight approach.\n\nThey can be used as stand-alone documents. But the structure is designed to be\nbest suited for use with the [`jupiter-policy-builder` CLI][builder] and the\n**policies** app on the **[JupiterOne][j1]** platform.\n\nThese are used internally at JupiterOne / LifeOmic Security.\n\n[j1]: https://jupiterone.com/features/policy-builder/\n[builder]: https://github.com/JupiterOne/jupiter-policy-builder\n\n## TL;DR\n\nRun the following command to install the policy builder and build the policies.\nYou will be prompted for a few inputs, such as company name, to be included in\nyour policy text.\n\n```bash\nnpm install -g @jupiterone/jupiter-policy-builder\n\npsp build -t ./templates\n```\n\nYou will be prompted to save the config to a file, which you can reference the\nnext time you'd like to rebuild the policies and procedures:\n\n```bash\npsp build -t ./templates -c path/to/your/config.json\n```\n\nThe result files are put in `./docs` (Markdown) and `./site` (HTML).\n\n**IMPORTANT:** To edit the policies and procedures, use the template files in\n`./templates` and re-run the `psp build` command. Do _not_ edit the `./docs` and\n`./partials` files directly as they will be overwritten on the next build.\n\nFor more detailed builder instructions, see the README [here][builder].\n\n## Format\n\nSimilar to the concept of \"micro-services\", the policies and procedures are\nwritten in \"micro-docs\" that are decoupled from the policies. They are mapped\nto each other via a JSON configuration.\n\n- All policies, procedures and reference documents are written in **Markdown**.\n- All configuration files are in **JSON** format, including mapping between\n  policies and procedures, and between procedures and compliance standards.\n\n## Structure\n\n`templates/policies`\n\n- This directory contains the modular templates for policies.\n- Each policy document is written in the following structure:\n\n    ```markdown\n    # Policy Title\n\n    `revision`\n\n    Overview of the policy. A paragraph or two to describe the intent and\n    principals of the policy.\n\n    ## Policy Statements\n\n    This section contains the high level requirements specific to the policy.\n\n    Policy statements are aligned to the organization's operating model and\n    applicable compliance requirements. These statements describe the \"what\"\n    but not the \"how\". They are meant to be stable over longer periods of time \n    without needing frequent updates.\n    ```\n\n`templates/procedures`\n\n- This directory contains the modular templates for controls and procedures.\n- Each procedure is considered a \"micro-document\" that describes how a specific\n  control is implemented to address the requirements in the policy that it\n  implements.\n- Each procedure document is written in the following structure:\n\n    ```markdown\n    ### Control/Procedure Title\n\n    Overview. A few lines to describe the control and procedure.\n\n    Detailed text.\n\n    #### Sub-section as needed\n\n    More text.\n    ```\n\n  \u003e Note that the **Title** is a _level 3 heading_. This is because the\n  `policy-builder` tool will automatically combine the procedures and policies\n  they each implement to a single document for publishing, and it will insert a\n  `## Controls and Procedures` section heading after the **Policy Statements**\n  section and before the first control/procedure.\n\n`templates/ref`\n\n- This directory contains the modular templates for reference documents.\n- The reference documents are similar to control procedures. At build/publish\n  time, they will be combined and attached to the **Addendum and References**\n  document by the `policy-builder`\n\n`templates/assessments`\n\n- This directory contains templates for assessment reports.\n- The only available report template at the moment is for a HIPAA risk assessment.\n- The `jupiter-policy-builder` CLI tool can leverage this template to\n  auto-generate a self assessment report based on the adoption of policies and\n  procedures.\n\n## Configuration and Mapping\n\n`config.json { organization }`\n\nThere are variables (e.g. `companyFullName`) defined throughout the template\ndocuments. These variables make it easy to adopt and maintain the policy set by\nconfiguring the variables at one place -- in the `organization` section of\n`config.json`.\n\nJupiterOne's policy builder (both the web app and CLI) makes use of this\nconfiguration to build the final policy set.\n\n`config.json { policies }`\n\nThe `policies` section is a repository of the policy modules. Each entry is\ndefined with the following:\n\n- `id` - typically matches the filename of the policy without the extension\n- `file` - path to the markdown module (without the `.tmpl` extension)\n- `name` - policy name, which typically matches the title in the policy doc\n- `adopted` - a `boolean` flag to indicate if the policy has been adopted by the\n  organization\n- `procedures` - an array that contains the procedure modules that\n  implement/enforce this policy.\n\nSimilar to the concept of \"micro-services\", the policies and procedures are\nwritten in \"micro-docs\" that are decoupled from the policies. They are mapped\nto each other via the above configuration.\n\n`config.json { procedures }`\n\nThe `procedures` section is a repository of the procedure modules. Each entry is\ndefined with the following:\n\n- `id` - typically matches the filename of the procedures without the extension\n- `file` - path to the markdown module (without the `.tmpl` extension)\n- `name` - procedure name, which typically matches the title in the procedure doc\n- `type` - specifies one of the following procedure types:\n  - `administrative`\n  - `technical`\n  - `operational`\n  - `physical`\n  - `informative`\n- `provider` - name of the control provider (e.g. \"AWS IAM\")\n- `summary` - provides guidance to the document author specific to that procedure\n- `applicable` - a `boolean` that specifies whether the procedure is applicable\n  to the organization based on its operational and compliance requirements\n- `adopted` - a `boolean` flag to indicate if the policy has been adopted by the\n  organization\n\n`config.json { references }`\n\nSimilar to procedures, the `references` section is a repository of additional\ndocumentation. Each entry is defined with the following:\n\n- `id` - typically matches the filename of the procedures without the extension\n- `file` - path to the markdown module (without the `.tmpl` extension)\n- `name` - document name, which typically matches the title in the procedure doc\n- `applicable` - a `boolean` that specifies whether the document is applicable\n  to the organization based on its operational and compliance requirements\n- `adopted` - a `boolean` flag to indicate if the policy has been adopted by the\n  organization\n\n### Compliance Mapping\n\n`standards/controls-mapping.json`\n\nThe `controls-mapping.json` document configures a mapping of each procedure to\none or more security/compliance frameworks, as applicable.\n\nNote that the controls mapping is only between a control/procedure document to\nthe requirement, not at the policy level. This is because we strongly believe\nthat you must have documented controls and procedures to implement and enforce a\nhigh level written policy. Having a written policy by itself without \nimplementation or enforcement does not address the risk of any security\nor compliance requirement.\n\nInternally at JupiterOne, we leverage CIS Controls and PCI DSS. JupiterOne's\nparent company, LifeOmic, builds a suite of healthcare related software products\nand is therefore under HIPAA regulation and has adopted HITRUST CSF.\n\nThe JSON documents for those four frameworks are included strictly because of\nour internal usage and shown as examples. Using those requires that you have\nobtained necessary end-user license for the framework for your own organization.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FJupiterOne%2Fsecurity-policy-templates","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FJupiterOne%2Fsecurity-policy-templates","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FJupiterOne%2Fsecurity-policy-templates/lists"}