diff --git a/README.md b/README.md
index 9a6bc6a..7228b23 100644
--- a/README.md
+++ b/README.md
@@ -2,9 +2,10 @@
 
 This helm chart is designed to deploy functionality that automatically saves core dumps from most public cloud kubernetes service providers and private kubernetes instances to an S3 compatible storage service.
 
-[![Artifact Hub](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/core-dump-handler)](https://artifacthub.io/packages/search?repo=core-dump-handler) 
-[![Docker Repository on Quay](https://quay.io/repository/icdh/core-dump-handler/status "Docker Repository on Quay")](https://quay.io/repository/icdh/core-dump-handler)
 [![build status](https://github.com/ibm/core-dump-handler/workflows/CI/badge.svg)](https://github.com/ibm/core-dump-handler/actions)
+[![Docker Repository on Quay](https://quay.io/repository/icdh/core-dump-handler/status "Docker Repository on Quay")](https://quay.io/repository/icdh/core-dump-handler)
+[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/5827/badge)](https://bestpractices.coreinfrastructure.org/projects/5827)
+[![Artifact Hub](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/core-dump-handler)](https://artifacthub.io/packages/search?repo=core-dump-handler)
 
 ## Contributions
 
@@ -165,8 +166,6 @@ helm delete core-dump-handler -n observe
 
 ## Build and Deploy a Custom Version
 
-The services are written in Rust using [rustup](https://rustup.rs/).
-
 1. Build the image `docker build -t YOUR_TAG_NAME .`
 
 2. Push the image to your container registry
@@ -187,36 +186,18 @@ or run the helm install command with the settings
 ```
 ## Testing
 
-1. Login to your kubernetes cluster so that `kubectl` can be ran from the script.
+### unit testing
 
-1. Ensure you have an minio client in your PATH on your machine.
+1. The services are written in Rust using [rustup](https://rustup.rs/).
 
-    ```
-    which mc
-    /usr/local/bin
-    ```
-1. If you don't have an minio client it can be installed on linux with
+1. Local unit tests can be ran using `cargo test` in the base folder
 
-    ```
-    wget https://dl.min.io/client/mc/release/linux-amd64/mc
-    chmod +x mc
-    sudo cp mc /usr/local/bin/mc
-    ```
-    Other OSes are detailed here https://docs.min.io/docs/minio-client-quickstart-guide.html
+### integration testing
 
-1. Publish the container definition for this project to a registry
+1. Currently only IBM Cloud ROKS and IKS are supported but we are happy to carry integration tests for other services but we can't run them before release.
 
-   ```
-   docker build -t REPOSITORYNAME:YOUR_TAG .
-   docker push REPOSITORYNAME:YOUR_TAG
-   ```
+1. To run the integration tests build follow the [instructions for a custom build](https://github.com/IBM/core-dump-handler/#build-and-deploy-a-custom-version)
 
-1. Modify the image definition in the yaml
-
-    ```yaml
-    image:
-    repository: REPOSITORYNAME:YOUR_TAG
-    ```
 1. In the root of the project folder create a file called `.env` with the following configuration
 
     ```
@@ -230,10 +211,18 @@ or run the helm install command with the settings
 
     ```
     cd integration
-    ./run.sh
+    ./run-ibm.sh
     ```
 
 
+## Releases
+
+Releases are built on a pre-release branch e.g. `pre-8.5.0` integration tests are ran manually and a release is generated when merged to main.
+
+It currently isn't possible to automate this as the kubernetes integration in github actions is not reliable enough.
+
+If you wish to test a pre-release with your own integration testing then please raise an issue and we can collaborate on your test run.
+
 ## Troubleshooting
 
 The first place to look for issues is in the agent console.
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000..3e7933e
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,39 @@
+# Security Policy 
+
+## Security Announcements
+Watch this project for issues raised about security and major API announcements.
+
+## Report a Vulnerability
+We're extremely grateful for security researchers and users that report vulnerabilities to the core-dump-handler Community. All reports are thoroughly investigated by community volunteers.
+
+To make a report email the `awhalley@ie.ibm.com` with the security details.
+
+You may encrypt your email using the keys of the [core developers](https://keybase.io/antonwhalley). Encryption is NOT required to make a disclosure.
+
+### When Should I Report a Vulnerability?
+
+You think you discovered a potential security vulnerability in core-dump-handler
+You are unsure how a vulnerability affects core-dump-handler
+You think you discovered a vulnerability in another project that core-dump-handler depends on
+For projects with their own vulnerability reporting and disclosure process, please report it directly there
+
+### When Should I NOT Report a Vulnerability?
+You need help tuning core-dump-handler components for security
+You need help applying security related updates
+Your issue is not security related
+
+### Security Vulnerability Response
+Each report is acknowledged and analyzed within 3 working days.
+
+Any vulnerability information shared will stay within the project and will not be disseminated to other projects unless it is necessary to get the issue fixed.
+
+As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated.
+
+### Public Disclosure Timing
+A public disclosure date is negotiated with the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Security Response Committee holds the final say when setting a disclosure date.
+
+## Supported Versions
+
+Versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
+
+The project maintains release branches. Currently we only support the most recent release and fixes will be applied to the next release and **will not** be back ported. We target at least one release every 3 months but this is *not* a guaranteed candence.
\ No newline at end of file
diff --git a/integration/run.sh b/integration/run-ibm.sh
similarity index 100%
rename from integration/run.sh
rename to integration/run-ibm.sh