Pratum Blog

Are you prepared for a SOC 2 Exam

If your customers want proof that you handle data securely, a SOC 2® report provides one of your best options. This industry standard continues to gain momentum as a way for companies to ensure that every vendor in their supply chain maintains proper security controls. For many companies, a SOC 2® report has become a requirement to win and keep contracts with key clients.

Getting your SOC 2® report isn’t a quick decision or process, so you’ll have to make a plan for how you will prepare for a SOC 2® exam. SOC 2® Type II represents a significant investment of time and resources, as the process typically takes at least a year, culminating with an audit by a Certified Public Account (CPA) firm. (If you’re unfamiliar with the overall SOC 2® process, read this blog for a summary.)

As you consider how to prepare for a SOC 2® exam, you have a couple of key decisions to make:


Should you hire a readiness consultant or try to prepare for the exam on your own?


Should you take the auditing firm’s offer to handle both readiness and the actual audit?

Facts to Consider Before a SOC 2® Exam

After helping dozens of companies prepare for their SOC 2® exams, Pratum has seen all the possible scenarios for handling this critical process. Here are several key points to keep in mind.

  • DIY preparation is more work than you think. As you consider how much money you’ll save by not paying a readiness consultant, be sure to factor in the extra workload that SOC 2® prep will put on your internal team. To keep up with all the other work that keeps happening, you’ll probably have to bring in additional temp help or postpone some projects.
  • An unfavorable SOC 2® report is costly. Auditors report what they find during the exam. They won’t comment on how you plan to fix any shortcomings in your security controls, and the process does not include a grace period for you to correct gaps before the report is issued. So if you have gaps, potential customers will read about them when they ask to see your SOC 2® report. (The report includes a place known as “Management’s Response” where you can comment on noted deficiencies, but the auditors won’t weigh in on your statements.)
    After you fix gaps, you’ll have to pay for another audit to get a report that shows that you now handle every area acceptably. The cost of a second audit will exceed what you would’ve paid a readiness consultant to help you get the desired result on the first try. Plus, a second Type II audit will probably take at least another 6 months. Are your current and potential customers willing to wait that long for you to get a SOC 2® report that satisfies them?
  • All-in-one services are rarely experts in everything. Some large CPA firms also offer cybersecurity services and will offer to help with both readiness and the audit. For simplicity’s sake, hiring one firm to handle the entire process certainly sounds attractive. (SOC 2® rules dictate that only CPA firms can perform the exams, so only CPAs can offer all-in-one service.) But the staffs of accounting firms rarely provide the deep expertise you get from a dedicated cybersecurity consulting firm. We’ve seen the best SOC 2® results come by teaming a cybersecurity consultant and a CPA firm that regularly work together on engagements. Because the teams collaborate frequently, you get all the benefits of a smooth process while tapping the expertise of pros from each category.
  • Cybersecurity consultants add insights from dozens of other clients. Consulting teams like Pratum’s take a deep dive into your business and its specific risk factors to help you develop the most applicable control sets during SOC 2® scoping. Their recommendations include best practices accumulated through engagements with numerous other clients. When you’re focused on getting your SOC 2® exam right the first time, you want support from experts that prepare dozens of companies for SOC 2® each year.
  • Proper scoping advice determines the outcome. Uninformed scoping can make a SOC 2® engagement harder, longer and more expensive than it needs to be. Readiness consultants help ensure that your engagement covers exactly what it needs to—but no more. A good consultant will have solid relationships with the auditors and will bring them into the scoping process to ensure that all sides agree on the rules of engagement before the work starts. If the scoping is inaccurate or vague, the auditors may dive into parts of your company that they don’t need to look at. Poor scoping also may leave out key elements that your clients want to see in the final report, which means you could spend a lot of money generating a report that doesn’t even speak to what your customers want to know.
  • Readiness consultants know what’s on the test. Nobody likes to guess about what they’ll be reviewed on. Experienced readiness consultants have dealt with enough auditors to know what they’re going to ask, what information they’re going to request during the fieldwork, etc. In many cases, readiness consultants work with the same specific people at the same CPA firms on multiple occasions. This familiarity between them makes your engagement go even more smoothly.
  • You need an advocate during the exam. Even if you’re working with a reputable, well-intentioned auditor, you’ll almost inevitably have some disagreements. In most SOC 2® engagements, clients almost always feel that the auditors are exceeding the agreed-upon scope in some areas. Or the client might feel that the auditor is incorrectly declaring a control insufficient because they don’t understand the scenario in which it’s being used. A good readiness consultant maintains a friendly relationship with the auditor—but makes clear that their job is to protect your interests. They will present your case to the auditor and provide supporting information to show them your point of view.

If you’re considering how to prepare for a SOC 2® exam, contact Pratum today to learn more about how we can help you plan an engagement that’s efficient and effective in growing your business.

An IT Manager's Guide to a Successful Audit
This article comes from a section of our paper An IT Manager’s Guide to a Successful Audit

The audit process can vary from engagement to engagement, company to company, or even auditor to auditor. But you should find that IT auditors take a consistent approach, even if the phases have different names based on the environment. It’s very important for you to fully understand the phases of your audit to ensure that you have the appropriate resources and input available at each stage. Just like in the Software Development Life Cycle (SDLC), it’s much easier and less costly to get all requirements for the project upfront so no future work has to be scrapped..

In this blog, we’ll cover these phases:

For each phase, we’ll describe the phase’s purpose and the role of IT management during that phase.

Announcement Phase

This is simply a time for the auditors to announce their intentions to audit a group, function, system, etc. Most internal audit departments try to plan their work in advance just as you do. They may even know their anticipated schedule a full year in advance. They probably won’t release any details other than a name for the audit, the audit manager or team leader, and a preliminary date. The longer the lead time, the more fluid plan will be. As in any other operational group, audit timelines slip due to personnel, weather, technology and other business drivers.

The timing of audit announcements can be brutal. Sometimes audits are on a cycle, and you know to expect them every quarter, every other year, etc. These audits are much easier to plan for. The associated workload is known, and you’ll have a staffing plan to deal with the resources the audit will require. Sometimes, however, the auditors show up without warning. That usually happens when something doesn’t go as planned. You might not have known the timing of the audit, but because of whatever happened, you probably expected an audit.

The announcement phase is the key time for you as an IT manager to begin preparing. This is also the phase that most of us ignore, which costs us dearly. Once an audit is announced, you should have ample time to begin getting ready. Take advantage of this time because once the auditors arrive, they will expect you to have your prep work done. Here are a few key ways to start preparing:

  • Start collecting and centralizing all information that auditors might request. Gather things like system documentation, work or change requests, policy, procedures, risk assessment information or penetration testing results. You may want to develop a documentation portal where you can store the information and give auditors granular access for a given period.
  • Review previous audits. Many teams overlook this. Do you have any outstanding issues that need to be resolved? This will be first on an auditor’s checklist. Make sure you’ve done everything you said you would after the last audit and documented it appropriately. Remember that police officers don’t give warnings when they pull you over for speeding and discover you have a pile of unpaid tickets.
  • Assign a point of contact (POC) for the auditors. This ensures you are kept in the loop regarding any changes. If the intended purpose or timelines change, you will want to be the first to know. You should also begin to plan for resource utilization to handle time-consuming audit responses. You need to make sure your people have availability during the engagement. If you see any red flags, talk with your auditor. Now is the time to try and adjust the schedule, not three weeks before they are on-site.
  • If you don’t have a self-assessment process, start one now. This shows auditors that you have a continual process and system reviews to identify any gaps and work toward remediation objectives.

Engagement Letter

Audit teams use engagement letters to spell out their specific objectives for an engagement. Perhaps they want to assess HIPAA compliance or review the effectiveness of your identity and access management controls. They should clearly define their intentions along with proposed timelines for each phase of the engagement. This is also a time for the audit team to introduce themselves to the business unit. Knowing the audit team and everyone’s role will help the entire engagement flow more smoothly.

Along with stating the audit objectives, the engagement letter summarizes the audit’s scope. This entails determining which systems can be reviewed and the look back period (date range for review) among other details. The scoping information is often just a best guess from the audit staff, as they probably don’t have the specific system knowledge to know if this scope is too big or too small to accomplish the stated objectives.

You should scrutinize the details of the engagement letter. Are the dates as expected? Is the objective clear? Has the objective changed from the initial announcement? Is the scope too broad or too narrow?

This is the time for you to drive the engagement. You have 4 key action items during the engagement process:


Confirm the overall timeline for each phase of the audit. Auditors are famous for trying to get in and get out as fast as possible, so you’ll need to review the timeline in light of the operational impact on your systems. Perhaps you’ll need to run 10 reports, which take 4 hours each to generate and can be run only in your evening maintenance windows after the backup runs. This might mean you can only run one per night, which means you need 10 days just to run the reports. If the auditor expects to finish gathering evidence in 5 days, you need to explain why this is unrealistic and negotiate a different timeline.

Don’t drag things out just to play it safe, though. Remember that the longer the auditor has to review and look over things, the more they uncover and the more they want to probe. This could expand the audit’s scope.


Set clear objectives for the engagement. Understanding the auditor’s goals will help you in the upcoming scoping phase. This is no different from getting business requirements from an operational unit before you begin coding their application. Another key in this step is understanding definitions. Even within the same company, acronyms and abbreviations may be used differently by different business units. Agree upfront on how you’ll communicate these items. Also, make sure to clarify what someone means when talking in technical terms. For example, people often throw around the terms “authorized” and “authenticated” interchangeably when discussing access controls. Make sure the term someone says is the term they mean.


Find out if the auditors have any pre-existing concerns about your organization or the systems. Unless you like being blindsided during the reporting phase, this is your time to get all the cards on the table. Auditors should tell you upfront about anything they are looking for. It’s not fair for you to be judged on criteria you don’t know about. You may also find you have some perception issues to work through to make this a successful engagement.


Take time to gain visibility into your problem areas. Do you have any gap remediation that management just hasn’t been willing to fund? When that gap becomes an issue in the auditor’s opinion report, management’s opinion is sure to change. Be careful, though. Your management may view this as an underhanded trick to get your pet project pushed through. Or if it becomes a big issue in the audit report, you might be on the hook for not having responded to it earlier. It takes some experience to balance getting visibility into known problem areas and just continuing to work on them in the background. We don’t recommend trying it on your first pass.

Scoping Activity and Self-Identifying Gaps

During the scoping activity, auditors tell you what systems they plan to review, what the lookback period will be, how many samples they plan to take, what the sample sizes will be, etc. Some of this information will be based on their previous experience with your organization or system. If this is an internal group that has performed the same audit several years in a row, their initial scope may be right on. If, however, this is the first time the audit has been performed, the team membership has changed, or the system has gone through a major revision, this might not be the case.

Your announcement phase should have included a self-assessment and gap analysis. That exercise may have resulted in some remediation plans. Most auditors will allow you to provide them with information regarding known gaps upfront. If you have an action plan and have made significant process on the plan, this can help improve your audit rating. Auditors are more concerned with ensuring things are done right than with who gets credit for finding the gap and making the changes. The scoping phase is a good time to disclose self-identified gaps. Some auditors prefer that this happens during the engagement negotiations, so be sure to check their expectations.

If negotiation isn’t one of your strong suits, you either need to develop your skills in this area or have someone on your team who can do it for you. Auditors are driven by best practices and repeatable processes. If the auditor feels you’re trying to get around these during the process, they will certainly push back. If you need to change the scope of your audit for any reason, you need to be prepared to justify your reasoning.

Simply thinking something will work better probably won’t sway an auditor. You and your team need to utilize your specific knowledge of the system architecture and operation to explain why the scope needs to be modified. For example, maybe the audit scope includes reviewing any authentication process for users of a web application. The architecture diagram provided to the auditor includes a proxy or load balancer in the middle. With your expert knowledge, you could explain how these devices have no direct impact on the authentication process and the logs can be excluded from this audit. The auditors will rely on your knowledge to help drive the scope. They don’t want to review meaningless data any more than you want to collect it for them.

Fieldwork and Control Testing


This is where most of the heavy lifting will take place. One of the first things an auditor will ask for is information relating to your process and procedures. They want to see how well these accomplish the successful implementation of your policy and related control standards. They will also be looking for whether all your controls are documented.

Auditors will interview system administrators to determine how they perform their duties daily and then check for supporting documentation. Written operating procedures are always best. Even if you’re doing the right things, if it’s not documented, you can probably expect that issue to be noted on your final review. Without the written documentation, there is no level of assurance that the process will be repeated the same each time. Staff transition or a disaster could prevent the regular administrator from performing their duties and cause the process to be changed if not documented.

Control Testing

Once the auditor has identified all the controls, they will review for effectiveness.

Before even looking at the system, the auditor will try to ascertain if a control can meet a policy objective. They will look at the control and assume it has been implemented correctly and consistently. They will also consider the technology aspect of the control and the system it was meant to protect. If there is a significant chance a policy could be violated even with the control in place, it probably isn’t going to be considered an effective control and will need to be reviewed. Sometimes this just means modifying the written documentation for the control to better reflect its design. Sometimes you’ll need to scrap the control and start over.

Once the auditors consider the control’s effectiveness, they will review it for efficiency. This is the point we see how well something works. While the control may be deemed effective, it may not be working well in the actual implementation. Perhaps it was implemented incorrectly or the process isn’t being followed. Many things can impact a control’s efficiency.

Since fieldwork is where the auditors begin to dive into your technology environment, you have home field advantage. Nobody knows the environment like you, so take advantage of that. Assigning a senior staff member as the POC assures the auditor that you take this engagement seriously and want to do everything you can to make it a smooth process. You also get the benefit that if the auditor tried to exceed the scope of the audit, your staff member will know the system well enough to catch and adjust the auditor’s focus.

Review Prepackaged Testing Scenarios

Some auditors come with prepackaged or predetermined testing scenarios. Make sure you review these to ensure they are appropriate for the way your environment is designed.

Databases and directory services are prime examples. Both can be customized to the point that they almost seem like in-house developed solutions. The standard fields an auditor tests may not be in use or may be used in vastly different ways by your organization. It’s important that both of you understand this before going through the laborious process of pulling data. Don’t be afraid to suggest scenarios you think will yield the results the auditor is looking for.

Many times, auditors ask for a report without any idea of what the report’s result will be. In one company, an auditor wanted to see information related to every Active Directory account in the company. Once it was explained that the company had over 210,000 accounts, that this would take about two days to run and that it would print out on about 30,000 pages, they changed their tune. The company was allowed to run smaller samples from several business units and finished with about 40 managers, 200 accounts and 5 pages. This was a statistically valid sample of the accounts, which would indicate whether the control was efficient. Work with your auditors to find valid samples instead of testing the entire environment.


Reports typically have two main sections:

Section 1: Opinion Statement

Auditor’s reports begin with their opinion statements on the overall effectiveness and efficiency of your organization’s controls. If all goes well and there are no major issues to report, this should be succinct.

In an internal audit, this will usually be no more than a couple of paragraphs and high level in nature, depending on the system complexity and audience for the report. External or regulatory audits are typically much longer. In most cases, there will be an executive summary section if the opinion section is more than a few pages. If your auditor has uncovered multiple deficiencies, the report will be as long as it needs to be to accurately describe the impact.

Section 2: Recommendations

The report’s second section offers recommendations. Auditors can’t be too specific here, as this would cause a conflict of interest when they go on to review the control. If they tell you step-by-step how to fix a control and then sign off on it in the next round, their motives would be suspect. If they again failed the control, you’d be none too happy with them. For this reason, they will tell you what needs to be fixed but not how to fix it.

As the audited organization, you have several key rights and responsibilities when it comes to the final report.

  • Remember that this audit process has been a partnership between you and the audit team. You should get to help shape the final report. After all, it is at least to some degree a reflection of how well you and your team do their job. You certainly don’t want your signature on a scathing report that you had no input on. If an auditor balks at including your input in the final report, this is a red flag that must be addressed immediately.
  • You should agree with all the facts in the report. You may not like everything that is stated or how it is stated, but there should be no assumptions. All the stated facts should be backed up with evidence from the fieldwork. Feel free to challenge the auditor and show additional evidence of your own if you believe the report to be inaccurate. It’s important to get these issues cleared up while the report is in draft format. You want a limited audience to see the “dirty laundry”. Once the final report is published, it’s hard to have it changed.
  • During this phase, you’ll also need to develop a timeline for remediating any identified control deficiencies. Most times you have a week or two at best to review the draft report and build a management response. There is little chance that you’ll fully understand the changes that need to happen or the impact on budget and operations. One smart approach is to commit to building a project plan by a certain date but not to fixing the problem. Committing to building a project plan shows you’re serious about fixing the problem but realistic about potential impact. Most auditors are fine with this because you will be tracking and reporting progress as you go. Just remember that the deficiencies need to be fixed before the next audit cycle.

To read the rest of the articles in our series on IT audits, download the complete paper here.

And if you need help planning or conducting an IT audit, contact us today.

Medical and HIPAA Compliance Icons with text overlay: Ensuring HIPAA Compliance

Many organizations play fast and loose with the phrase “HIPAA-compliant.” But this isn’t a mere marketing label that everyone can apply however they see fit. HIPAA’s standards for achieving and maintaining compliance are admittedly confusing in many areas. But there ARE HIPAA best practices and standards—well-documented ones at that.

In this blog, we’ll offer insights on two specific areas that frequently cause confusion around HIPAA compliance: cloud services and voice over IP (VOIP).

Is Encryption in Cloud Services Required?

Whenever you see “HIPAA-compliant” and “cloud service provider” in the same sentence, expect things to get confusing. Don’t automatically accept a service provider’s claim that their cloud service is HIPAA-compliant. In their default state, many implementations using cloud services actually aren’t. If a cloud service provider states they are HIPAA-compliant, they generally mean that their platform can be used in a HIPAA-compliant manner if configured and used appropriately.

For instance, many cloud services do not currently enforce encryption at rest when data is stored on their platforms. (Data at rest is simply data that is being stored rather than data being transmitted or processed. It could be, for example, data stored on a hard drive, in a .txt file, or in an Amazon S3 bucket). In many cases, encryption at rest is a configurable feature/option, but you’ll have to manually turn it on. To make matters even more confusing, at rest encryption can be implemented in many different ways, such as full disk encryption; volume or virtual disk encryption; file/folder encryption; and even database table/field encryption. And, of course, no two cloud providers or solutions do things exactly the same way.

If you don’t encrypt data at rest in cloud environments used to store Protected Health Information (PHI), you will often be non-compliant with HIPAA. That naturally leads to the question, “If HIPAA requires encryption at rest, why doesn’t it just say so?” Here are the details.

 The HIPAA Security Rule and the U.S. Department of Health and Human Services (HHS) do not explicitly require implementation of encryption at rest in every situation. (This is one of the safeguards called "addressable" in HIPAA parlance, which means “not required.”) But HIPAA does require that every organization conduct a risk assessment to determine whether encryption is a "reasonable and appropriate safeguard" for PHI data at rest for their organization in every situation. (This section of HIPAA has the details. Note that HIPAA handles all of its "addressable" safeguards this way.)

Furthermore, HHS has acknowledged that "encryption protects ePHI by significantly reducing the risk of the information being viewed by unauthorized persons.”

Why Encryption Makes Sense

Along with HHS’ recommendation, every covered entity and healthcare organization we’ve worked with has expected that PHI be encrypted at rest when it is outside of the organization’s direct control. Your decision should be even easier when you learn that it doesn’t cost much in time or money to implement at rest encryption.

All of that is why we recommend encrypting PHI in two situations:

  • Whenever PHI leaves your data center/office and your organization's enforced/monitored physical and logical security controls.
  • Whenever PHI resides in a place where it could be stolen more easily, such as cloud services and mobile devices.

Encrypting data in these situations mitigates the risk of data loss. You will be protected in the event of breakdowns of physical or logical security controls in cloud service provider environments or at other potentially uncontrolled locations (such as remote work locations).

Keep in mind that if you want to pass a HIPAA audit, you’ll need to take additional measures for any location/service where you don’t encrypt PHI data at rest. HHS states, "If the entity decides that the addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate."

Basically, if you decide not to encrypt PHI in a cloud service, you need to document that ahead of time, along with details of the equivalent alternative measures/safeguard you use. All of that must be available to any auditors who come calling from the Office for Civil Rights (OCR, which enforces HIPAA).

For more information on how HIPAA applies to cloud service providers, click here.

Voice Services

Voice services and voicemail present their own HIPAA complexity. Part of the challenge stems from the fact that HIPAA arrived long before anyone used VOIP. HIPAA was released in the same year (1996) that VOIP was invented (specifically, the SIP protocol). But VOIP didn’t hit widespread usage among healthcare providers until around 2011. (Here’s a quick history of VOIP).

HHS has said that telephone and fax services are exempted under the HIPAA Security Rule because they are written and oral communication. But that’s not the end of the story.

This overview of HIPAA’s treatment of telephone and fax services illustrates the challenge. It doesn't address VOIP or video over IP services specifically.

We suspect HIPAA exempted telephone service in the first place because encryption of voice communications wasn’t considered a reasonable and appropriate safeguard in 1996. Transit encryption was ridiculously expensive/difficult to implement for voice transmissions, and voicemail as a service didn’t exist. And no one had even thought about the concept of cloud providers.

The best way to avoid non-compliance in an audit or penalties from OCR is to use transit encryption with VOIP or video services. Both history and recently released information from HHS point to this:

  • HHS tacitly admitted that cloud voice/video providers in general may not be compliant.
  • HHS also indicated that voice/video traffic transmitted over the Internet should be encrypted and that a breach caused by interception of PHI voice or video transmissions sent over the Internet could lead to OCR penalties.

If you need help understanding how HIPAA rules affect your organization, contact us today.

Get our blog posts delivered to your inbox:

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.