Cyber Security and Compliance:
The Ultimate Guide for Businesses

Organizations and business associates in the healthcare space are governed by specific policies under HIPAA, the Health Insurance Portability and Accountability Act.
 

As a consumer of healthcare services, you wouldn’t want anyone gaining access to your personal health data or any other personal data, for that matter.
 

Similarly, if you owned a healthcare practice, you wouldn’t want patient data exposed to unauthorized parties.
 

The HIPAA standard mainly focuses on protecting this kind of patient information, including PHI (Patient Healthcare Information), which is identifiable healthcare information about any individual, and PII (Personally Identifiable Information).
 

In conjunction with PII, PHI allows you to associate a person with a condition.
 

Overseen by the Department of Health and Human Services / Office of Civil Rights, HIPAA focuses on how PII is disclosed and who it is disclosed to.
 

What requirements does HIPAA outline?

 
To safeguard against unauthorized individuals gaining access to PHI or PII, organizations in the healthcare vertical should abide by the following basic requirements.

• Risk assessment – threats to PHI and associated countermeasures must be assessed annually
• Protection of PHI/PII from “unauthorized disclosure”
• Personnel procedures – screening, termination, rights changes
• Defined policies and procedures, specifically a Privacy Policy
• Incident response and continuity plans
• Mandatory training on the organization’s HIPAA policies
• Means to handle contractual obligations with business associates

 
Another requirement outlined in HIPAA is the types of risk assessments that should be undertaken.
 
For organizations in the healthcare space, a risk assessment should cover several basic areas:

• Threats to the organization that could potentially disclose PHI/PII unnecessarily
• Adherence to the principles set forth within the HIPAA security rule (NIST 800-66 rev1) 
• Vulnerability assessments if reasonable and appropriate to understand the threats and further penetration testing to prove their exploitability if necessary

These risk assessment should be conducted by a BA (Business Associate).

Does a BA need to be HIPAA-compliant?

A BA only needs to be HIPAA-compliant if they directly handle PHI or PII from the organization.

If services are not directly related to PHI, the BA only needs to be covered by a BAA (Business Associates Agreement) that governs the BA’s security posture and how an incident/breach would be handled.

How does Miles handle HIPAA assessments?

Aligning your organizational policies with HIPAA requirements will help protect patient data.

To help keep your organization HIPAA-compliant, we provide several services related to risk assessments and information security.

HIPAA risk analysis/assessment

We complete a thorough risk assessment and rank the findings in terms of priority. From there, we conduct a gap analysis against the provisions of the security rule and derive an exceptions report indicating what clients need to address to improve their compliance.

Information Security Program Documentation

All entities need some form of policy/procedure documentation that governs how they appropriately handle data and security.

Vulnerability Assessments and/or Penetration Testing

If the client’s maturity level is appropriate, additional vulnerability assessments or penetration testing can be added to the scope of the risk analysis.

Complementary Controls

These controls can help organizations abide by the HIPAA standard and include MFA, Bitlocker, Least Privilege model application, Log collection, and incident response.

Our Managed IT services include proactive services and powerful cyber security to help abide by HIPAA requirements.

With many organizations accepting credit cards for payment nowadays, PCI is crucial to ensure data is processed and stored correctly.

PCI stands for Payment Card Industry and focuses on the security of cardholder data in an effort to reduce fraud around credit card transactions.

If you handle credit card data in any capacity, you need to adhere to the PCI standard to keep customer information safe and secure.

The CDE (Cardholder Data Environment) helps define the scope of what needs to be protected.

Remember, the LESS you have direct influence over when it comes to credit card transactions, the fewer controls you need to adhere to.

What systems are subject to PCI compliance?

Since PCI compliance is related to the safe handling of credit card information, you may think that only the systems directly handling transactions need to be PCI compliant.

In reality, every piece of equipment in your environment needs to be compliant.

For the most part, any computing equipment that can directly communicate with each other in the CDE must follow PCI controls.

These include networks, computers, servers, and terminals that accept, process, transact, store, or handle credit card data.

This also applies to any other piece of computing equipment that exists on the same segment of the network and can communicate with each other.

What are SAQs?

Once you know the types of equipment that need to be protected, you can take steps to ensure your environment is PCI-compliant.

To ensure your setup aligns with the requirements outlined in the standard, anyone who handles credit cards must complete the SAQ (Self Assessment Questionnaire).

There are different levels of the SAQ depending on whether your organization stores or processes credit card data locally or outsources it to a third-party payment gateway.

What are common scenarios related to PCI?

Even though your corresponding SAQ will outline relevant controls you must adhere to, it’s important to consider common scenarios that may drive higher-level organizational decisions.

Should I keep my systems in-house or host them elsewhere?

One scenario customers often face is whether to keep their payment systems in-house or host them elsewhere.

Remember that part of the hosting cost is based on keeping the hosted system compliant.

As a result, there will be fewer requirements to adhere to on your end if you choose a hosted system.

Once your system is brought in-house, you’ll face increased costs for establishing compliance.

Is there any scenario where I don’t need to be PCI-compliant?

In short, no; any business that accepts credit card payments must abide by the PCI standard.

• A customer who accepts credit card transactions using a standalone dial-out phone-based terminal does not accept credit card payments through or associated with their website and processes less than 1,000,000 transactions in a year STILL needs to be compliant.
• Similarly, a customer whose ecommerce website redirects users to a payment gateway to check out and processes only 20,000 transactions per year STILL needs to be compliant.
• If you process one credit card transaction over a year using an imprint machine that has triplicate carbon paper forms, you are STILL technically responsible for being PCI compliant.

I work with a PCI-compliant vendor. Does that mean my organization is PCI-compliant?

No. Using a PCI-compliant vendor does not automatically make you PCI-compliant.

If you are required to be PCI-compliant, and you use a third-party vendor, they are not necessarily required to be PCI-compliant.

They are simply required to adhere to your controls as they pertain to third-party vendors and their security.

CMMC v2

 
In the same way that PCI is required for companies who accept credit card payments, the CMMC standard is for organizations who do contract work with the US Department of Defense.
 
CMMC stands for Cybersecurity Maturity Model Certification and was created by the US government to protect controlled, unclassified information.
 
These standards are used to measure an organization’s overall security posture.
 

What are the levels of CMMC compliance?

 
Although any organization contracting with the government should obtain CMMC compliance, the appropriate compliance level depends on their type of work.
 

Level 1

If the organization falls into the Level 1 category, it must complete a self-assessment/attestation (similar to the SAQ for PCI compliance).
 

Level 2

Most organizations will fall into this category; they will likely need to undergo an assessment by a third party.
 

Level 3

These organizations have only one option: assessment by a third party, which will be held to both the NIST 800-171 and NIST 800-172 frameworks. 
 

How does Miles handle CMMC assessments?

 
Any organization that faces CMMC must take security seriously.
 
They must also have a “System Security Plan” and follow the directive and technically specific controls as part of that plan.
 
Miles IT can help with CMMC assessments by assisting with security policy documentation and implementation.
 
Often, documentation is the first place to start. Information Security Programs can guide organizations through the process of building up their security posture and implementing specific items to enhance security.
 
If proper documentation is already in place, gap analysis is a likely next step. This entails identifying what controls are already in place versus what controls should be in place.
 
Although CMMC looks to regulate how organizations handle specific data, you should already take security seriously when handling any data.
 

FISMA & GLBA

 
In the same way that CMMC matters if your organization does contract work with the US Department of Defense, FISMA and GLBA are compliance standards for organizations with government contracts.
 
FISMA stands for the Federal Information Security Modernization Act and was first enacted in December 2002.
 
The standard focuses on obtaining an ATO (Authority to Operate), which allows you to interact with a federal government agency or someone adjacent to a federal government agency.
 
It necessitates developing and documenting a System Security Program (Information Security Program) and requires a Security Assessment Report by a 3PAO (3rd Party Assessment Organization).
 

Who does FISMA apply to?

 
FISMA applies to federal agencies and other related agencies or enterprises.

• Federal agencies, contractors, or other sources that provide information security for the information systems
• State agencies implementing federal programs (Medicaid, Medicare, student loans)
• Private enterprises that manage government contracts, provide services, or receive grant money

What are the FISMA requirements?

 
To ensure your organization remains compliant, there are specific requirements associated with FISMA.
 
FISMA requirements include:

• Security plan in place. This should outline how your organization handles information security as related to your operations.
• Assigned responsibility for security. This documents who is responsible for security at your organization.
• Authorize system processing before operations and periodically after. This means if you grant people access and give them specific roles, they are reviewed to ensure they are authorized to interact with the system as intended.
• Periodically review security controls. This means that your organization undertakes formal due diligence to ensure security controls work and make sense.
• Annual FISMA Certification and Accreditation. This is a formal and audited practice.

 
Complying with these requirements will help maintain your ATO so you can continue providing services.
 

What is GLBA?

 
Like other regulated standards, the GLBA standard governs how consumer information is disclosed to other parties.
 
GLBA stands for the Gramm-Leach-Bliley Act and is mainly applied to financial institutions. 
 
It protects NPI (nonpublic personal information) and how it is disclosed to non-affiliated third parties.
 
In the same way you wouldn’t want your healthcare information to be unknowingly shared, you wouldn’t want your financial status, transaction history, or other data exposed.
 
NPI includes the following: 

• Any information an individual shares to get a financial product or service (name, address, income, Social Security number)
• Any information gained about an individual from a transaction involving your financial products or services (account numbers, payment history, loan or deposit balances, credit or debit card purchases)
• Any information gained about an individual in connection with providing a financial product or service (information from court records or a consumer report)

 
Governed by the Federal Trade Commission, GLBA ensures the security of customer information, protects against threats, and secures against unauthorized access to that information.
 

What are the GLBA requirements?

 
GLBA has specific requirements in order to protect financial information.

• Information Security Program requirements, including documented policies, processes, procedures, and assigned responsibility
• “Clear and conspicuous” notice of an organization’s privacy practices
• Risk Assessment
• 3rd-party oversight
• Evaluation of the information security program and the controls being defined
• Actually having controls designed to safeguard NPI

 
These control activities are similar to those audited in a SOC 2 audit, which we will discuss in more detail later.

Like the SOX standard, SOC 2 (Service Organization Controls) audits are based on the COSO framework and report on organizational controls.

Unlike the SOX standard, SOC audits consider organizations as a whole instead of restricting oversight to financial activities only.

Keep reading to learn more about SOC 2 compliance and the audit process.

What is SOC 2 compliance?

SOC 2 compliance is important from an organizational perspective because the final report can be shared with customers, business partners, and prospects to assure that controls are in place.

Third-party validation can instill a sense of security in entities looking to work with your organization.

A SOC 2 audit reports on an organization’s controls as related to security, confidentiality, availability, processing integrity, and privacy.

Though it is a non-public report, it can be shared with individuals as it makes sense for your business.

What is the difference between Type I and Type II audits?

SOC 2 reports can be issued in two different ways, depending on your organization’s needs.

Type I reports validate that the design and description of control activities are sufficient for what the controls aim to achieve. They simply observe a point in time.

On the other hand, Type II reports serve to validate the effectiveness of control activities. They are measured over a longer period and may sample from 6 months up to 2 years to see how well the controls work over a broader time span.

Typically, an organization audited for the first time will undergo a Type I audit. From there, they can undergo a Type II audit if necessary.

Can you fail a SOC audit?

Though organizations can receive unfavorable results on their SOC audit, no “pass/fail” terminology exists.

SOC 2 provides an objective, independent view of an organization’s controls.

However, the opinion is either Favorable, Qualified, or Unfavorable.

A Favorable opinion means that the auditors did not take note of any exceptions in any of the controls, their presence, or the ability to provide evidence that the control is in place.

A Qualified opinion means that though there were exceptions present, they were not material enough in nature to be categorized as an unfavorable opinion.

An Unfavorable opinion means that the auditor found so many exceptions that they represented material failures in the control activities.

Although you cannot fail a SOC 2 audit, an unfavorable opinion may make organizations less likely to work with your company.

If the audit provides the reasonable belief that certain control activities are not present, outside organizations may not view your organization as credible.

What is COSO in SOC 2?

You may wonder what regulations guide SOC 2 audits if you cannot pass or fail the audit.

As previously mentioned, the COSO framework provides the necessary guidelines and requirements for SOC 2 audits.

It includes both required and optional points of focus to guide the activities that should be in place.

In other words, COSO communicates to auditors and organizations being audited, “What do you need to account for in your controls?” 

The framework does not tell organizations to take specific, pre-defined actions with their controls but guides what the organization should include and define.

Required focus points include:

• Establishes Policies and Procedures
• Evaluates Competence and Addresses Shortcomings
• Attracts, Develops, and Retains Individuals

What is TSC?

As we’ve seen with the COSO framework, organizations are simply given guidance and told what to think about regarding their controls with a SOC 2 audit.

The COSO framework used to be known as TSC (Trust Services Criteria).

The framework does not instruct organizations, “Do X in exactly this manner.”

Instead, it prompts them to think about it and define the control activities themselves.

What’s involved in a SOC 2 audit?

Now that you recognize the importance of a SOC 2 audit, you may wonder what the process looks like.

It begins with an engagement letter from the auditor outlining the audit plan, including the type of audit, time span, and governance.

Depending on the audit firm, they may have one or multiple “observation or field visit” meetings.

Often, specific artifacts are collected independently and later provided to the auditors for review.

However, observations must always be conducted as well to maintain thoroughness and attention to detail.

What does an auditor do?

By understanding an auditor’s role, you can better prepare the correct documentation and artifacts to ensure a smooth process for all parties involved.

• Inquiries
• The auditor will ask specific questions about whether your organization has certain controls in place. If you answer “yes,” they may ask for additional details.
• In general, inquiries carry less weight than observations, but not everything can be observed.
• Inspection – Static point in time
• Inspections are typically by artifact.
• Observation – Static point in time
• Observations are typically by systems/configurations.
• Observation – Population & Sample Set
• To demonstrate the “over time” nature of a SOC 2 report, auditors will establish the total populations for specific controls and determine how much of a sample set they need to observe to give confidence in the effectiveness of the controls. Notably, this has recently changed, where sample sizes have the potential to be substantially larger under new guidance. 

The anatomy of a SOC 2 report

Understanding what your SOC 2 report will look like can create clear expectations for your team and the third party requesting the audit.

Typically, SOC 2 reports include up to 5 sections.

• Section I: Independent Service Auditor’s Report. This outlines the document’s meaning and provides clarity around the subject matter.
• Section II: Management Assertion of Organization. Similar to Section I, this provides more information about the meaning of the SOC 2 report. It also summarizes the auditor’s opinion regarding the controls’ design, implementation, and effectiveness.
• Section III: Description of the Service Organization’s System. This section is incredibly important, providing a narrative description of the organization and its control systems that are then audited in Section IV. This section can be broken down further into smaller components.
  1. Services Provided
  2. Principle Service Commitments and System Requirements
  3. Components of the System – this includes infrastructure, software, and people
  4. System Incidents – this may not be included in every report. The goal is to share whether incidents occurred during the assessment period and how they were handled.
  5. Complementary User Entity Controls – this discloses responsibilities the customer must undertake to ensure they are receiving services securely
  6. Complementary Subservice Organization Controls – this shows that the organization has examined the subservice vendors they work with and has done the work to validate their compliance and security. 
• Section IV: Testing Matrices. This section outlines what the auditor did to confirm that what was noted in Section III was actually present. You can’t have something listed in Section IV that is not referenced in Section III.
• Section V: (NOT AUDITED) Other Statements. This section shares other qualified statements the organization would like to make.

Once your SOC 2 report is completed, you can share it with other individuals or partners at your discretion.

Now that we’ve discussed different types of compliance standards and audits that may be relevant to your organization, it’s important to consider other policies and control documentation that should be in place.
 
In general, you should have policies in place that are relevant to the controls in your organization.
Most times during an audit, the reason for an unfavorable opinion is that the control activities documented by the organization were not actually in place.
 
The documentation should accurately reflect what the organization is actually doing, not what they want to try and do or what they think sounds reasonable.
 
Another important point to remember is that usually about 50% of an audit is documentation.
 
These documents are typically what an organization uses to tell an auditor what they are doing, so the auditor knows what to measure against.
 
Keeping these documents factually accurate and up-to-date is critical, which may mean avoiding absolute phrases or statements.

 

What are common documents that every organization should have?

 
Although the types of documents you should have to depend on your organizational policies, there are several common documents that every organization should have.

• Information Security Program
• Documented Decisions by Senior Management
• Incident Response Process – even if it details how you hand it off to a third party that is working with you
• Change Management
• Breach Notification
• Vendor Risk Management
• Disaster Recovery & Business Continuity Plan (DR&BCP)

 
When we work with organizations, we consider whether they have these documents in place.
 

What is a cyber security policy document?

 
A cyber security policy document is clear, audience-specific content that provides rules, guidelines, and a framework for how the organization expects sensitive data to be handled, processed, stored, or otherwise interacted with.
 
It also includes controls relative to physical access, authentication, data retention, data disposal, incident response, change management, disaster recovery, training, and more.

 

What should be covered in a security policy document?

 
Security policy documentation should be audience-specific; it shouldn’t be just one document.
 
There should be multiple documents based on who reviews or interacts with them.
 
For instance, controls that pertain to end users are in a collection of other controls that only pertain to end users.
 
That end-user document should not include content only related to senior management.
 
In addition, security policy documentation should be clearly written.
 
It should avoid phrases that make it seem the organization hasn’t done something yet, such as “the organization will do X.”
 
Documentation should be objective and clearly outline what expected behavior vs. unexpected behavior looks like with respect to security control.

 

Are there any IT security documentation templates I can use for my company?

 
Generally, we dissuade against using an IT security document template and simply filling in your organization’s name in the blanks.
 
Though templates do exist, they are usually written generically. As a result, organizations may not understand the full scope of the procedures and practices they are committing to.
 
As a consequence, there could be a variety of issues, including:

• Undefined statements. Templates may use language like “organization-defined frequency.” If an organization fails to define that period of time, the document will be incomplete.
• Commitment to practices that are not being followed. If the document hasn’t been read thoroughly and checked for irrelevancies, the organization may commit to procedures they are not actually following.
• Pre-defined, finite frequencies that are not adhered to. The template may include language like “all,” “annual,” or “monthly,” when the reality may be something less frequent or defined.