With headline-grabbing software vulnerabilities becoming more and more prevalent, now is the time to tighten up your development practices into a well-written SDLC policy. This particular information security policy will help your development teams standardize on coding tools and practices, as well as get everybody on the same page from a security standpoint. And come the time when you do have a incident, you will be able to demonstrate to your customers that you do indeed take their security seriously - it’s not just lip service.
In the world of SOC 2, the general rule is to write a policy, procedure or log entry for just about everything that happens in your environment. This is especially important when it comes to system changes, as auditors want to see that you have detailed logs of what’s happening in your environment, that the changes are properly documented and communicated across your organization, and that you can effectively debug problems after a change is made. All of these requirements and expectations are defined in your system changes policy.
As you prepare your company to endure and recover from a disaster, two primary information technology policies should be in place: business continuity and disaster recovery. These two policies help you plan for – and recover from – adverse events, but the difference lies in the goals of each policy: business continuity focuses on returning your business to normalcy, while disaster recovery details the minimum necessary functions for your business to survive.
When an information security incident occurs, you need to be able to gather as much information about it as quickly as possible. There’s also a very real possibility that you will have to involve outside parties - such as an incident response team - to help you as well. That means you can’t approach log management and retention as a simple checkbox. Instead, you need to have rich data that captures audit logs from all critical information systems. Otherwise, if your logs are incomplete, inaccurate or missing altogether, they won’t be of much help when you really need them. Here are five questions to ask when writing your log management and review security policy:
Here are four practices to consider when creating your IT vendor management policy: 1. Evaluate vendors IT services vendors are generally very good at assuring you their product or service is like oxygen - you can’t live without it! They will throw around a lot of acronyms and buzzwords like “next-gen” in hopes of dazzling you into signing on the dotted line. Resist that temptation for now, and instead create a template with questions to help you do the proper amount of due diligence and select the right vendors.
Passwords are one of the most common targets for hackers, so it’s imperative that your company enforce 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 SOC 1 and SOC 2 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 and SOC 2.
You scheduled your on-site SOC 2 testing. While the initial step is complete, there is still a lot of process and time before you’re past the finish line. This post will help plan and manage time expectations and establish a timeline of deliverables - working backward from your SOC audit start date. The Purpose of SOC 2 Audits SOC is a system of service organization controls. SOC stands for “system and organization controls,” and controls are a series of standards designed to help measure how well a given service organization regulates its information, user entities, and sensitive data - particularly customer data. The purpose of SOC standards is to create a level of confidence and trust for organizations when they engage third-party vendors. A SOC-certified organization (hey, that will be you soon!) has been audited by an independent certified public accountant who worked with your organization on a readiness assessment
HIPAA. NIST. ISO. FedRAMP. FISMA. SOC 2. These are just a few of the acronyms for compliance frameworks that your customers may be asking you about. The big question your organization needs to answer is, “Which compliance is right for me?” This blog post will focus on helping you understand some of the popular compliance frameworks, and specifically how they relate to SOC 2. HIPAA vs SOC 2 HIPAA (Health Insurance Portability and Accountability Act) is a United States law developed by the Department of Health and Human Services. The main objective of HIPAA is to protect patients’ medical and health information - such as health plan details and doctor visits. However, the protections HIPAA aims to provide will not attest to your organization’s maturity in terms of privacy and security. This is where SOC (Service Organization Control) comes in. SOC was created by the AICPA (American Institute of Certified
It’s safe to say that not many service providers look forward to soc 2 compliance. I'd guess not many of you have the AICPA on speed dial. Whether you're preparing for a Type 1 or Type 2, audits may be perceived as events that you prepare for and complete, but then eventually they go away - at least for a while. To stay SOC 2 compliant we suggest a paradigm shift. Treat compliance as a continuous process rather than a point-in-time event. Unlike taxes, there is no 'audit-season.' Here are some tips for always being prepared for your next audit. Embrace the idea that policies and procedures evolve After spending considerable time getting your policies and procedures just right to address the trust services principles, it’s tempting to step back and say, “Good, we finally have all this great documentation, now let's not touch it again until we absolutely have