Physical security is not just a concern for large companies. A small business also needs an established physical security policy to protect their physical assets and provide their employees with a sense of protection and safety. In this policy, you will define the controls, monitoring, and removal of physical access to your company’s facilities. Here are five practices for writing your office physical security policy: Create an access control system
Writing Your BYOD PolicyThis article will point you to the core concepts of BYOD, removable device, and cloud storage policies so that you understand best practices before writing your own. Removable media, cloud storage, and BYOD devices can be a quick and convenient way for employees to handle data. But with this convenience comes some serious security concerns. Unprotected removable storage is an easy entry point for end users to
SOC 2 compliance, like so many things related to IT and security, is chock full of terms and acronyms to learn. If you are just getting started with SOC 2, it’s helpful to get familiar with this alphabet soup ahead of time so you can move your compliance efforts forward with confidence. Below is a SOC 2 terminology glossary to get you started: AICPA The American Institute of CPAs, formed
Writing Your Security Incident Response PolicyThis article will point you to the core concepts within the SIRP so that you understand the purpose of this policy before writing your own. The Security Incident Response Policy (SIRP) establishes that your organization has the necessary controls to detect security vulnerabilities and incidents, as well as the processes and procedures to resolve them. The tricky thing about this policy is that it needs
Despite thousands of articles, there's shockingly little actionable advice to help startups complete SOC 2. When you don't have dedicated compliance teams or six figure budgets, we set out to answer: When to pull the trigger on SOC 2. Who needs to be involved in prep work & what tasks can/can not be delegated. How to narrow the scope and save as much time as possible. What are achievable best
In this post, we’ll answer the following questions:How do I know what rules and regulations I need to follow when protecting my data and data center? Where should I host my secure data center infrastructure (on-prem vs. colocation facilities vs. cloud vs. hybrid solution)? How do I plan for - and recover from - a physical data center failure?
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: