Documenting and communicating policy and system changes in your organization can be an arduous task. But the effort becomes more manageable when you have a plan in place before an emergency.
In this episode Justin McCarthy sits down with Andrew Mulholland, head of core infrastructure at BuzzFeed to talk about security incident response, remote access policy, and a money-back guarantee for OSS.
The first step in this policy is to define the critical processes and assets necessary for you to maintain minimum business functions after a disaster.
As you work through the rigorous SOC 2 requirements, it is easy to get tunnel vision because so much of your work focuses on protecting your customers and their information. But what about the vendors you work with? Do you have a third-party IT vendor management strategy to address the risks they bring to your organization?
Passwords are one of the most common targets for hackers, so it’s imperative that your company enforces a strong password policy. This policy will not only define the requirements of the password itself but the procedure your organization will use to select and securely manage passwords.
Confusing a SOC 1 vs SOC 2 audit is easy. While both compliance frameworks attest to the controls used within your organization, the frameworks differ in focus. SOC 1 looks at your organization’s financial reporting, while SOC 2 focuses on how you secure and protect customer data. This blog post will focus on exploring the differences between SOC 1 vs SOC 2.
This is the first step to create an audit trail of PostgreSQL logs. Postgres can also output logs to any log destination in CSV by modifying the configuration.
You wouldn’t leave the house without making sure your doors and windows were locked, and that any valuables were hidden or secured in a safe. That way, if you were robbed, the burglar would have a difficult time accessing your most precious assets. In the same way, you need to make sure your organization’s critical data is well protected.