@@ -89,3 +89,21 @@ SOC 2 is about showing how you operate—document and share your processes.
|
|||||||
- [Have a security page](TRA.001_have_a_security_page.md)
|
- [Have a security page](TRA.001_have_a_security_page.md)
|
||||||
- [Clearly explain your services](transparency/TRA.002_clearly_explain_your_services.md)
|
- [Clearly explain your services](transparency/TRA.002_clearly_explain_your_services.md)
|
||||||
- [External support available](TRA.003_external_support_available.md)
|
- [External support available](TRA.003_external_support_available.md)
|
||||||
|
|
||||||
|
### Review and keep things up to date
|
||||||
|
|
||||||
|
## Why does it matter?
|
||||||
|
|
||||||
|
Your company changes over time, and so should your security posture.
|
||||||
|
|
||||||
|
## How can I proceed?
|
||||||
|
|
||||||
|
Some things don’t need review (eg: MFA is enabled), but your infrastructure and
|
||||||
|
your employee are changing.
|
||||||
|
|
||||||
|
⇒ You need to make sure people and digital asset with access are the one working
|
||||||
|
today in/with your company.
|
||||||
|
|
||||||
|
- [Remove unauthorized assets](core/infra/COR.INF.007_asset_decommissioning.md)
|
||||||
|
- [Conduct an access reviews](personnel/access/PER.ACC.006_periodic_access_review.md)
|
||||||
|
- [Test your disaster recovery plan](operations/incidents/OPS.INC.003_drp_testing.md)
|
||||||
|
|||||||
29
controls/core/infra/COR.INF.007_asset_decommissioning.md
Normal file
29
controls/core/infra/COR.INF.007_asset_decommissioning.md
Normal file
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
id: "COR.INF.007"
|
||||||
|
category: "core/infra"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "1h"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC2.1", "CC6.8"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Remove unauthorized assets
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Outdated/unmonitored/etc.. assets (VMs, Buckets, etc..) pose a significant risk:
|
||||||
|
|
||||||
|
- They can be used for malicious activities
|
||||||
|
- You don’t manage them, they could lack proper security measures.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
Review the list of authorized asset you created
|
||||||
|
[List of your assets](./COR.INF.001_list_your_assets.md) , identify the ones
|
||||||
|
that should not be there, and select the proper action:
|
||||||
|
|
||||||
|
- Disconnect the asset from your network
|
||||||
|
- Scan for security updates on the asset and ensure proper access control
|
||||||
29
controls/operations/incidents/OPS.INC.003_drp_testing.md
Normal file
29
controls/operations/incidents/OPS.INC.003_drp_testing.md
Normal file
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
id: "OPS.INC.002"
|
||||||
|
category: "operations/incidents"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-15"
|
||||||
|
estimate-time: "6h"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC3.2", "CC5.1", "CC7.5", "CC8.1"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Test your disaster recovery plan
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Having a plan with dust on it is useless. The goal of having a Disaster Recovery
|
||||||
|
Plan is to be able to insure business continuity. As things are moving in your
|
||||||
|
company, you need to check whether your DRP is still legit and whether you are
|
||||||
|
able to properly run it.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
At least once a year, you need to test your DRP and, if possible, improve it.
|
||||||
|
Follow the instructions on yours and log the outcomes. Did it work?
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Link to the logs of your last test
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
id: "PER.ACC.006"
|
||||||
|
category: "personnel/access"
|
||||||
|
revision-version: 1
|
||||||
|
revision-date: "2024-01-14"
|
||||||
|
estimate-time: "30m"
|
||||||
|
necessity: "mandatory"
|
||||||
|
frameworks:
|
||||||
|
- name: "soc2"
|
||||||
|
sections: ["CC3.3", "CC6.1", "CC6.2", "CC6.3", "CC6.5"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Conduct an access reviews
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
A formal/explicit process to review employee access on a quarterly/yearly basis
|
||||||
|
is a must have in terms of security hygiene.
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
Every 3 or 6 months, plan an “Access review session” with the relevant people to
|
||||||
|
audit accesses on all systems (that is another good reason to enable SSO). You
|
||||||
|
need to ensure everyone has the proper access for his/her job - an account
|
||||||
|
inactive for the last 90 days can probably be disable. If you proceed to any
|
||||||
|
change, document it in the minutes of the meeting - those minutes will be asked
|
||||||
|
for subsequent SOC 2 audits.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Screenshot the recurring meeting invite OR the notes from the previous reviews
|
||||||
Reference in New Issue
Block a user