So you’ve decided whether you need a SOC 1 or a SOC 2 audit…what’s next? You need to decide where you’ll begin the SOC audit process. With a gap analysis? What are the SOC report types? A Type I? A Type II? Let’s discuss KirkpatrickPrice’s method for completing Type I and Type II audits.

SOC Report Types: Type I and Type II FAQs

No matter the SOC report types needed (SOC 1 or SOC 2), there are a few common questions we receive from service organizations going through the SOC audit process for the first time, and they involve deciding between SOC report types.

Do I need a Type I or a Type II report?

The key difference between a Type I and Type II report is the attestation on the operating effectiveness of controls. A Type I report is an attestation about controls at a service organization at a specific point in time, and a Type II report is an attestation about controls at a service organization over a period of time. Observing controls over a period of time allows for verification that controls are suitably designed and operating effectively – whereas a Type I report attests that controls are suitably designed and implemented.

Many questions about the SOC report types depend on what your client is asking for. If they are satisfied with a Type I report, you may elect to undergo that audit and stop there. If you’re undergoing these audits to be proactive, we recommend getting a Type II report – but this doesn’t always mean you skip the Type I.

Do I have to go through a Type I audit before a Type II audit?

It is not a requirement to go through a Type I audit before you go through a Type II audit – but it is our recommendation. Gaining a Type II attestation on your very first audit will be a difficult process for your team – you have to be prepared to show your policies, controls, objectives, and commitment to compliance, all while establishing that your controls have been operating effectively for at least six months. Going through a Type I audit first gives you the opportunity to learn how the SOC audit process works, establish your control objectives, learn where your areas of weakness are, and discover what you need to improve before the Type II audit. We have found that when a service organization rushes to get a Type II report, the final result isn’t as valuable as it would be if they had prepared better for the audit.

Want to hear from a client that received both SOC report types within a year? Read about Sigstr’s SOC 2 journey here.

Do I need to go through a gap analysis before the Type I? What about the Type II?

Whenever any organization goes through any audit for the first time, we strongly recommend starting with a gap analysis. By starting the SOC audit process with a gap analysis, our auditors can identify any operational, reporting, and compliance gaps in your organization and advise you on strategies for remediation. Gap analyses compare what you’re doing to what regulations require of you. Once you receive the results of the gap analysis, your organization can remediate any identified gaps before the audit begins.

For a first time SOC audit, a basic audit map may be: a gap analysis first, then the Type I audit, then the Type II audit. If you elect to skip the Type I, you can still choose to go through a gap analysis before the Type II audit. In some cases, organizations have thought they should skip the Type I audit, but after receiving their gap analysis results, they thought it would be wise to undergo the Type I before the Type II.

What happens if I fail the Type I?

SOC audits do not work on a pass/fail system. The purpose of a SOC report is to provide user entities with reasonable assurance that their controls are suitably designed and operating effectively. Instead of passing or failing your organization, an auditor will issue a qualified or unqualified opinion. Understanding reasonable assurance changes your pass/fail mindset to considering how an auditor would assess specific controls. Would an auditor see that these controls are suitably designed? Would we achieve reasonable assurance? If an auditor determines that a control was not in place or effective, then a qualified opinion would be issued. This would sound something like, “Except for Control X, reasonable assurance is there. The controls have been suitably designed and operating effectively.” An unqualified opinion means there are no qualifications or significant exceptions being issued and reasonable assurance has been determined.

KirkpatrickPrice’s Type I and Type II Process

Because so many service organizations are completing a SOC audit at the request of a client, many are on a strict timeline for the SOC audit process. That is why, at KirkpatrickPrice, we’ve developed a streamlined SOC audit process to get service organizations through a gap analysis, Type I, and Type II audit in a faster way, but without losing quality. By electing to undergo both a Type I and Type II audit, we actually give you more resources to help your team make SOC audit process more valuable. No one should have to begin a Type II audit unprepared because of timelines.

Contact us today and let’s talk about how we can partner together to get you through the SOC audit process and achieve your compliance goals.

More Type I and Type II Resources

What’s the Difference Between SOC 1, SOC 2, and SOC 3?

SOC 1 or SOC 2: Which SOC Report Do I Need?

The Difference Between SOC 1 Type I and Type II

The Difference Between SOC 2 Type I and Type II

When information security, data security, and cybersecurity measures aren’t followed in development, staging, and production environments, the consequences can be detrimental. We’ve seen that time and time again. Last year, a bug bounty discovered a data breach at Imperva – a leading provider of firewall services. How did it happen? An unauthorized user stole an administrative API key from a production AWS account. What was the mistake behind Uber’s 2016 data breach? Developers published code that led to hackers gaining access to developers’ privileged accounts and to Uber’s servers.

Are your developers following the security standards you’ve put into place? Are you aware of the security concerns with DevOps? Let’s discuss how to securely manage multiple environments, from development to deployment.

Development, Staging, and Production Environments

A typical development workflow has three environments: development, staging, and production. Some developers don’t view staging as an environment, but we included it here to give you a full scope of the process.

Development Environment

A development environment is on your computer. It’s the environment where you’ll conduct all your code development without touching with the actual data. In development, you can test upgrades, new features, and improvements without impacting the customer’s view. You may find bugs along the way, but that’s what this environment is meant to discover.

Ideally, the development environment is similar to the production environment, with the same operating system, tools, software libraries, and a copy of the product data. Developers will often use virtual machines or container systems like Docker to mimic the production environment, ensuring that code that works in development will also work in production. 

Typical use-cases for a development environment include:

  • Building new features, extending existing features, and code refactoring.
  • Running integration tests. 
  • Debugging.

There are few restrictions on what developers can do in their development environment, and they are free to experiment with code until they are happy with it, at which point they will push it to the staging environment.

Staging Environment

The staging environment is a production-like environment to see how your code will perform. This is the final testing ground before the code is pushed into production. Staging environments are often used for:

  • Quality assurance and performance testing.
  • Vulnerability testing and risk analysis.  
  • Integration testing, to ensure that the code integrates well with services and databases the app depends on. 

Staging environments also give other developers, project managers, and clients an opportunity to examine software before it goes live. 

Because extensive testing takes place in the staging environment, it’s important that it is as similar to production as possible, including both the software and hardware. While it’s fine to host a development environment on a laptop, the staging environment should be on a server with the same hardware it will run on in production. 

Production Environment

In a production environment, systems go live and your developed code is released to end-users. You deploy completed code that has endured proper vulnerability testing and risk analysis. All of the testing is complete and there’s the expectation that you’ll find only minor bugs, if any. Once it’s released, you’re relying on it as a profit source, so you want to make sure it’s secure

In theory, major bugs and software vulnerabilities should have been discovered before the code goes to production, but that’s rarely the case for complex software systems. It is likely that at least some bugs made it through testing, so organizations must design and  implement network and data security systems that assume the existence of vulnerabilities. 

Importance of Security Throughout Dev, Staging, and Production

With multiple environments comes the difficulty of securely managing them. Best practice is to separate your development, staging, and production environments. This allows each to evolve at its own pace – maybe the development environment is testing out features that won’t be available in production for at least a year – and reduces the risk of cross contamination. Any bugs discovered in staging, for example, will be contained within that environment and not spread any further. Most importantly, keeping your development, staging, and production environment separate will help protect data.

In audits or penetration testing, we see many organizations failing to test their test all of their environments, but there could be a vulnerability in the test environment that compromises the production environment. It’s problematic to avoid testing all environments.

Security Concerns in DevOps

For organizations that use the DevOps approach, security is an even greater concern. It’s face-based, there’s more overlap, there’s automation – there are many reasons to implement and verify security processes in DevOps.

To preserve high-level compliance practices within your development, staging, and production environments, you can implement configuration management techniques, monitoring and logging processes, and even integrate infrastructure as code or policy as code. You can set yourself up for success by performing regular code review during the development process, making changes proactively to all environments, confirming that you have limited access to the proper channels, or even engage in continuous penetration testing to ensure no vulnerability is overlooked. These practices will ensure you’re doing your due diligence to securely manage your various environments.

If you’re interested in advanced penetration testing services that will locate your vulnerabilities and help you avoid harmful gaps in your code, KirkpatrickPrice can help! Contact us to learn more.

More DevOps Security Resources

Think Like a Hacker: How Could Your Mobile Apps Be Compromised?

Best Practices for Configuring Your AWS Perimeter

PCI Requirement 6.5 – Address Common Coding Vulnerabilities in Software-Development Processes

In a day and age where mobile apps are heavily relied on for business, social interaction, and everyday activities, we have to ask: is there really a place for mobile apps in our election system? Or, more importantly, do we emphasize the security of mobile apps enough to allow them to play such a critical role in our elections? The Iowa caucus coding errors revealed at the 2020 Iowa caucuses is a sobering reminder that this is not the case just yet, and many developers have a long way to go when it comes to developing applications that are secure enough to hold a place in our election system.

So, what happened in Iowa? What can we learn from it? Let’s discuss.

What Were the Coding Errors at the Iowa Caucus?

The Iowa caucuses were held on Monday, February 3rd, 2020, and what should have resulted in a clear winner only resulted in confusion, frustration, and ultimately, distrust in the election system. After the 2016 elections, where there was much discussion and skepticism over hacking and foreign interference in the election, the stakes and expectations around election integrity in 2020 are high. As the infamous first caucus took place, Iowa instantly fueled more fears about the 2020 election season when they contracted a third party, Shadow, Inc., to create a mobile application that would tally the caucus results.

As the caucus took place, precinct leaders quickly realized the mobile app did not operate as intended. Many received error messages upon login filled with undecipherable tech jargon. Others simply could not get the mobile app to open. The developers apologized for the delays through a series of tweets and a statement on their website, but the realizations about the app, its development, and the negligence on behalf of the Iowa Democratic Party were striking.

3 Key Takeaways from the Iowa Caucus Mishap

Vendor Management

As we often point out at KirkpatrickPrice, vetting vendors is one of the most important decisions a business will make, and in this case, the Iowa Democratic Party is learning that lesson the hard way. When they partnered with Shadow to provide a mobile app for tallying purposes, they failed to investigate the development procedure and status of the application before using it. Instead, they blindly trusted this third party to provide a secure mobile app that ultimately was released in a beta version. When thorough code review or penetration testing isn’t performed before putting an app into production, it can have damaging effects.

Mobile App Security

With an influx of IoT devices and mobile apps, DevSecOps is a hot topic and security must be ingrained in the development process instead of being something that developers review after the product is made, or even worse – after it’s put into production. In Shadow’s case, they failed to thoroughly test the product before allowing it to be used. This is especially surprising because they were contracted to create this app specifically for the Iowa caucuses. They released a beta version knowing that it could encounter errors and have trouble being used by large amounts of users. According to some reports, they didn’t even distribute the app through Apple’s App Store or the Google Play Store – both of which have rigorous security testing measures in place. Why didn’t they do this? What motivation was more important than securing the app used for such an important event?

Relying on Personal Devices

Regardless of the security issues found within Shadow’s app, the mere fact that the Iowa Democratic Party instructed precinct leaders to download the untested, unsecure mobile app on their personal devices is asinine. Personal devices are increasingly susceptible to vulnerabilities that can easily be tampered with and exploited by malicious third parties.

While what happened in Iowa outraged many people and further heightened the fear of yet another year with election issues, it’s not the first time an organization failed to properly vet a third party, nor is it the first time a mobile app developer failed to properly undergo thorough security testing, like the kind of mobile app pen testing we offer at KirkpatrickPrice. And, unfortunately, it’s likely that this won’t be the last time. As technology develops and continues to modernize the way we do business and go about our lives, we have to consider if we are ready to modernize our elections. Do we value security and privacy enough to ensure that our election system won’t be compromised by negligence or malicious users?

More Resources

What is Mobile Application Penetration Testing?

Vendor Due Diligence Checklist

Think Like a Hacker: How Could Your Mobile Apps Be Compromised?

Disclaimer: This blog post does not reflect any political position of KirkpatrickPrice, Inc.

Internal Audit Validates Controls

Austin, Texas – Medici, a virtual healthcare company based in Austin, today announced that it has completed its SOC 2 Type II audit. This attestation provides evidence that Medici has a strong commitment to deliver high quality services to its clients by demonstrating they have the necessary internal controls and processes in place.

SOC 2 engagements are based on the AICPA’s Trust Services Criteria. SOC 2 service auditor reports focus on a service organization’s non-financial reporting controls as they relate to security, availability, processing integrity, confidentiality, and privacy of a system. KirkpatrickPrice’s service auditor report verifies the suitability of the design and operating effectiveness of Medici’s controls to meet the standards for these criteria.

“Security and compliance commitments are critical for Medici providers and patients, and we are dedicated to providing service and data security assurance as part of our mission to recreate the doctor-patient relationship,” said Allen Darnell, Chief Technology Officer at Medici. “Our new attestation with the SOC 2 Type II standard demonstrates Medici’s enduring commitment to ensuring the security and continuity of our critical customer operations.”

“The SOC 2 audit is based on the Trust Services Criteria. Medici has selected the security, processing integrity, and confidentiality categories for the basis of their audit,” said Joseph Kirkpatrick, President of KirkpatrickPrice. “Medici delivers trust-based services to their clients, and by communicating the results of this audit, their clients can be assured of their reliance on Medici’s controls.”

About Medici

Medici is working to change how healthcare is delivered by recreating the doctor-patient relationship. With the secure messaging app, physicians and patients have the ability to connect via text, call, or video, from anywhere and on their schedule. This enables patients to chat with their doctor, vet, or therapist at any time, and clinicians to extend care and get paid without extra overhead or burdensome schedules. With over 20,000 doctors across the platform, Medici is leading the way in the future of healthcare.

How Can C-Levels Overcome Compliance Challenges?

The growth and maturity of the security function will only rise as far as its leader’s capacity. Cyber and compliance threats are advancing, threatening our organizations’ financial and human resources. Because of this, business leaders must learn how to overcome the potential mistakes they make when it comes to information security and compliance and develop our leaders to face the potential mistakes we make when it comes to information security and compliance. What are some of the common mistakes C-level executives make when it comes to overseeing security and compliance? In this webinar, Joseph Kirkpatrick will teach executives how to conquer challenges like implementing a culture of security throughout your organization, overcoming the language barrier of cybersecurity and technology, common misconceptions around security and privacy, and developing the talent of your personnel.

The First Mistakes Executives Need to Overcome

When first establishing your business culture, what did you want it focus on? Integrity? Team-oriented atmosphere? Maybe even fun? While these are all notable components to a business culture, if security is remotely of any interest to you, you’ll also include it the culture you establish. Why? Because whatever you base your culture on – whether it’s teamwork or security – it’ll be something you’ll train on regularly, discuss often, and your personnel will be more likely to actively participate in the culture. How can you do this? By creating a cybersecurity culture management plan. This plan should define your organization’s security objections, establish education and training requirements, and place personal responsibility on employees to ensure security. After all, everyone – regardless of your position in the company – plays a role in security.

Culture Training is a Necessity

If you aren’t conducting some type of culture training, you should be. As millennials become a bigger portion of the workforce, businesses are experiencing increasing security incidents. While in the past, it was considered that the older generations – those with less technology experience – were more like to fall victim to social engineering attempts, millennials are the ones that pose the greatest threat to your business as they’re more likely to share and connect with strangers online. Because of this, you must adjust your training. Ask yourself: Are you providing the necessary and the right training to the newest members of your workforce? Do you millennial-aged personnel know not to share sensitive information online? What happens if they do?

Is your security culture non-existent? Need more information on culture training? It’s never too late to address the culture of security at your organization. Learn more about conquering this challenge and how to overcome four other mistakes by watching the full webinar now.