The SOC Audit Process: Tackling Type I and Type II Reports

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

Security Within Your Development, Staging, and Production Environments

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.


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.


The staging environment is a production-like environment to see how your code will perform. This is your chance to perform QA processes, run performance tests, and detect any other bugs before you push the code live.


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.

Importance of Security Throughout Multiple Environments

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 Coding 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

The 2020 Iowa Caucus Mishap: A Failed Attempt to Modernize Elections

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 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 Happened in Iowa?

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?

Vender Due Diligence Checklist (With Downloadable PDF)

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

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

Encrypted Backups: What They Are and How to Use Them

Today’s cyber landscape is riddled with advancing threats. From simple phishing attacks to intricate DoS attacks, businesses must ensure that the data they collect, use, store, and transmit is properly and thoroughly secured. After all, the data that companies hold is one of their greatest asset, so being aware of the consequences associated with losing that data is essential. For this reason, we believe that it’s imperative that organizations encrypt their backups. So, what are encrypted backups? What do you need to know about how to encrypt backups? Let’s discuss.

What is an Encrypted Backup?

To put it simply, an encrypted backup is an extra security measure that is used by entities to protect their data in the event that it is stolen, misplaced, or compromised in some way. Often times, however, many businesses confuse encryption with hashing. Let’s be clear: they are not the same.

Hashing vs. Encryption

The main difference between hashing and encryption is that a hash is not reversible. You cannot take a hash value and derive the original source. In fact, a hash acts somewhat as a fingerpoint, and it’s known to attack (i.e. collisions or rainbow tables). On the other hand, encryption is reversible. It can take the ciphertext and derive the original source if the decryption keys are known.

How to Encrypt Backups

There are various ways to create encrypted backups. If you’re stuck on determining how to encrypt backups, you can start by determining which method is best for your organization by considering factors such as types of data stored, environment types (cloud, hybrid, physical), personnel and technical experience, industry, applicable framework requirements, and more. The most common types of encryption are symmetric and asymmetric.

Common Types of Encryption

  • Symmetric Encryption: Symmetric key algorithms for cryptography that use the same cryptographic keys for both encryption of plaintext and decryption of ciphertext.
  • Asymmetric Encryption: Asymmetric encryption is a form of encryption where keys become come in pairs. Frequently, but not necessarily, the keys are interchangeable, in the sense that Key A encrypts a message, then Key B can decrypt it and vice versa. With asymmetric encryption, both the private and public keys make up the key pair, and both are required to encrypt and decrypt the data.

Framework and Legal Requirements for Encryption

While this list is not exhaustive, some of the most common framework and legal requirements for encryption include the following:

  • PCI DSS: Requirement 3.4 says, “Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: one-way hashes based on strong cryptography (hash must be of the entire PAN), truncation (hashing cannot be used to replace the truncated segment of PAN), index tokens and pads (pads must be securely stored), strong cryptography with associated key-management processes and procedures.”
  • HIPAA: According to the HIPAA Security Rule technical safeguards, 45 CFR § 164.312(a)(2)(iv) includes an addressable requirement that covered entities and their business associates, “Implement a mechanism to encrypt and decrypt electronic protected health information.” While this requirement is nebulous, you can learn more about the requirements here.
  • GDPR: Article 32(1)(a) states, “Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: the pseudonymisation and encryption of personal data.”

Benefits of Encrypted Backups

It’s no secret that data is a highly sought-after asset, and malicious hackers and organizations will stop at nothing to get their hands on your organization’s data. However, internal threats are equally as important to consider. But, if you’re proactive and implement robust encryption practices to protect your backups and data, you can reap many rewards. For example, in IBM’s 2019 Cost of a Data Breach Report it’s explained that “extensive use of encryption, data loss prevention, threat intelligence sharing and integrating security in the software development process (DevSecOps) were all associated with lower-than-average data breach costs. Among these, encryption had the greatest impact, reducing breach costs by an average of $360,000.” Aside from lowering the potential cost of a data breach, encrypted backups can protect your organizations assets, position you organization as a trustworthy and reliable organization, and provide your customers with the peace of mind they deserve.

Still questioning what an encrypted backup is? Need more information on how to encrypt backups? Contact us to talk to one of our Information Security Specialists today, and let KirkpatrickPrice be your expert partner as you navigate how to ensure the security of your data through encrypted backups.

More Information Security Resources

How to Scale Your Information Security Program as You Grow

Is Endpoint Protection a Comprehensive Security Solution?

Are Your Remote Employees Working Securely?

Combining SOC 1 and SOC 2 Audits

We get a lot of questions about SOC 1 and SOC 2 audits. What’s the difference between the two? Should your company do both? Are you able to consolidate multiple audits into one project? KirkpatrickPrice has developed the Online Audit Manager to make it easier to combine multiple audits into one project. Let’s talk through why and how you would take on the project of a combined SOC 1 and SOC 2 audit.

What are SOC 1 and SOC 2 Audits?

Before we discuss how to go through a combined SOC 1 and SOC 2 audit, let’s review what each of these types of audits are. What does a SOC 1 audit assess? A SOC 1 audit is an assessment of the internal controls at a service organization which have been implemented to protect client data. SOC 1 audits are performed in accordance with the Statement on Standards for Attestation Engagements No. 18 (SSAE 18) standard and report on the effectiveness of internal controls at a service organization that may be relevant to their client’s internal control over financial reporting (ICFR).

A SOC 2 audit is a second type of SOC assessment of the internal controls at a service organization that protect client data. The SOC 2 audit was designed to determine if service organizations are compliant with the principles of security, availability, processing integrity, confidentiality, and privacy (also known as the Trust Services Criteria) – which are typically unrelated to ICFR. The Trust Services Criteria are the foundation of the SOC 2 audit, just as the SSAE 18 is the basis of a SOC 1 audit.

Why a Combined SOC 1 and SOC 2 Audit?

Why would a company pursue a combined SOC 1 and SOC 2 audit? The obvious reason is that you may have clients that are specifically asking for SOC 1 and SOC 2 reports from you. They want to know whether you are handling their data in a secure way. You could also have some asking for one audit or the other. In some circumstances, your clients may not even know which one you need, but they want you to prove your security practices are legitimate – so it’s up to you to determine whether you’ll undergo a SOC 1, SOC 2, or a combined SOC 1 and SOC 2 audit. Whenever your clients (especially key accounts) or stakeholders have specific compliance requirements, it’s always a wise decision to do your due diligence and know what your options are for meeting their requirements and industry standards. To effectively ensure that your controls meet the demands of the variety of clients and stakeholders that you serve, you should know that a combined SOC 1 and SOC 2 audit is an option.

Here’s what some of our clients have to say about their combined SOC 1 and SOC 2 audit with KirkpatrickPrice:

  • “Trust and transparency is a core Rhumbix value. As a leading provider of construction technology, it is important for us to provide SOC 1 and SOC 2 reporting for our customers and ensure we continue to build and architecture future Rhumbix products with the highest standards. ” – VP of Development at Rhumbix
  • “The successful completion of our SOC 1 and SOC 2 Type II examination audits provides our clients with the assurance that the controls and safeguards we employ to protect and secure their data are in line with industry standards and best practices.” – Information Security Officer at Inovatec
  • “CBOSS is committed to delivering robust, secure solutions for payment processing to all our customers. To that end, we strive to make security and reliability integral to every aspect of our operations. We appreciate the KirkpatrickPrice’s thoroughness and we are proud to have met or exceeded all the requirements they validated.” – Security and Compliance Manager for CBOSS
  • “Upholding security regulations is critical as a service provider. Completing the SOC 1 Type II and SOC 2 Type II audits provides validation to OneCloud customers that we’re committed to keeping our platform secure.  OneCloud will annually renew our SOC certification by maintaining the necessary controls and processes.” – Chief Executive Officer of OneCloud

Using the Online Audit Manager

Our goal is to make SOC 1 and SOC 2 reports more accessible to organizations who are being asked for them, so in order to complete a combined SOC 1 and SOC 2 audit, we utilize the Online Audit Manager. The Online Audit Manager is an online audit delivery tool that maps the requirements of each framework to one another so that you can capitalize on your resources instead of answering the same question over and over again on separate audits – all with the goal of saving your organization’s time, effort, and money. Completing a combined SOC 1 and SOC 2 audit with KirkpatrickPrice will be a more efficient, accessible process for your organization. Interested in more specifics on how this works? Let’s set up a demo of the Online Audit Manager.

More SOC 1 and SOC 2 Resources

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

Using the Online Audit Manager to Complete Multiple Audits

4 Reasons the Online Audit Manager is the Audit Tool You’ve Been Missing