The recent release of the Interim DFARS rule has raised a lot of concern and questions among U.S. Department of Defense (DoD) contractors.

The Interim Rule updates how the DoD expects these contractors, collectively known as the Defense Industrial Base, or DIB, to protect Controlled Unclassified Information (CUI) by formally outlining the transition plan to the Cybersecurity Maturity Model Certification (CMMC)  and updating the current NIST SP 800-171 compliance requirements. 

Regarding the end-of-November rule change for DFARS Clause 252.204-7012, the updated rule outlines how the CMMC framework will be implemented and why. It also gives the NIST SP 800-171 compliance “Interim Rule” requirement teeth, and companies are concerned about making sure they are compliant. 

CMMC is a standard set by the U.S. Department of Defense that was first announced in January 2020 in order to respond to significant compromises of defense-related information housed on its contractors’ IT systems. It’s implemented across the Defense Industrial Base (DIB) sector, with more than 300,000 companies in the DoD’s supply chain, and the goal is to eradicate compromises of information stored within contractors’ information systems.

A-LIGN has continued to work with clients since the certification was announced to answer questions that help individuals and organizations understand and prepare for CMMC. It’s important for us to be at the forefront of CMMC to help demystify its implications for our clients. We are also in constant contact with experienced partners to discuss the pros and cons of CMMC, the challenges and benefits, and the newest developments of this rapidly evolving framework. 

CMMC FAQs

Some of the most frequently asked questions about CMMC are where to begin, what to do, how much it costs, and how long it takes. A-LIGN recently hosted a panel of industry experts to discuss CMMC, and there was unanimous agreement that organizations should get started now with Level 1 processes and build their program from there. CMMC Survival Guide is the webcast that A-LIGN hosted with Kris Martel, CISO, Emagine IT; Alex Hall, VP of government programs, Alluvionic; and Bernhard Bock, CISO/CIO SysArc. While we covered a lot of ground in the discussion, highlights included scope, process maturity and technical considerations. Another resource, our introductory overview of the CMMC framework, is detailed in CMMC Explained: Practices, Process, Domains and Levels, created by A-LIGN.

CMMC will be implemented using a five-year phased rollout strategy. Starting October 1, 2020, only certain contracts will require CMMC certification, so it’s important to be ready and get the process started now. If your organization is handling Controlled Unclassified Information (CUI), you will need to prepare for Level 3. By October 1, 2025, all contracts and orders, excluding commercial off-the-shelf (COTS) products or under the federal micro-purchase threshold, will include a CMMC-level requirement for companies to meet. This means to participate in a DoD contract a “Contractor shall have a current (i.e. not older than 3 years) CMMC certificate at the CMMC level required by this contract and maintain the CMMC certificate at the required level for the duration of the contract,” according to proposed DFARS clause 252.204-7021 wording. 

Cost of CMMC certification and scope 

One of the most common questions about CMMC is “how much is this going to cost me?” And since the cost is directly related to scope, no one will really know until the Department of Defense begins releasing RFIs and RFPs that include CMMC. DoD has assumed for the phased rollout of CMMC that roughly 30% of DIB contractors will require CMMC Level 3, which is the equivalent of NIST SP 800-171, plus an additional 20 practices (controls) with about 74% of those DoD contractors considered small business. 

Practically speaking, the scope of CMMC will focus on where data is stored, processed and transmitted, employees (and contractors) coming into contact with CUI, and systems (such as email and accounting) with access to CUI. Smaller companies may find it easier to just consider everyone and everything in their organization in scope, but larger organizations will face more complexity during their scoping process. Starting at level 1, which includes 17 security controls that are widely considered industry best practices—you most likely have many of them already implemented – will lay the groundwork for your effort and give you a place to start. That way an organization can start with the basics and work up from there. 

CMMC Certification Levels and Technical Considerations 

CMMC specifies five certification levels, which reflect the maturity level and reliability of a company’s cybersecurity infrastructure, as well as how much DoD information they have access to or store. The levels are tiered and each builds upon the previous level’s technical requirements. Higher levels require a contractor to comply with the requirements of lower levels fully and institutionalize the processes needed for specific cybersecurity practices. 

Level 1, Level 3 and Level 5 are the most relevant. Level 1 is based on FAR 48 CFR 52.204-21, Level 3 is based on NIST SP 800-171, and Level 5 is based on Draft NIST SP 800-172. Since CMMC is based on existing security frameworks, most organizations won’t have to start from scratch, but they will need to take stock of their existing controls to determine what is missing. 

The most obvious controls, which many organizations already have implemented, include endpoint protection, encryption, multi-factor authentication, permissions, audits and logging. The next level of controls includes ingesting threat intelligence and configuration management. It is important to realize there is no silver bullet solution to achieve CMMC compliance; it takes defense in depth. And it is equally important to focus on mindset: doing the right things, the right way. 

CMMC Requires Organizational Changes

Speaking of doing the right thing, process maturity is often overlooked as part of this certification process, in favor of technical controls. Companies must keep in mind that in order to achieve a specific CMMC level, a company must demonstrate both process maturity and the implementation of practices, or technical controls, commensurate with that level. 

It is naïve to think that CMMC is just an IT problem; it is also a people problem—and it takes training and organizational changes to achieve. Processes should not overlook the human element.  

A Managed Security Service Provider (MSSP) is one logical choice to help achieve CMMC compliance, since they enable an organization to leverage economies of scale, from basic to advanced tools. But, just as there is no silver bullet solution for technical considerations, it is important for organizations to be wary of any MSSP that claims to have a ready-made CMMC solution. That is because every organization is different, so it is critical that an MSSP understands your business and can map to CMMC.  

The takeaway message is don’t wait. Get started today on your path to CMMC certification. Take the time to conduct due diligence for solution and service providers to make sure they can adequately address your needs. And keep your eyes open for the upcoming launch of the CMMC Marketplace, which will list vendors and service providers that have received official CMMC training from the CMMC Accreditation Body as either a consultant/service provider or as a certified assessor. 

For many organizations, obtaining a System and Organization Controls (SOC) attestation report is table stakes for doing business. Many customers and vendors won’t even consider working with an organization that can’t produce a SOC report issued by an independent third-party assessor. Going through a SOC examination for the first time can seem overwhelming, but by taking the time to work through a simple audit checklist, many organizations can set themselves up for success.

What is SOC Compliance?

Companies are often asked if they are “SOC compliant” or if they can provide proof of “SOC compliance.” These terms can create confusion around what a SOC report represents, because SOC itself is not a compliance framework. SOC reports are attestation examinations performed by an independent third party to assess whether the organization’s internal controls are designed and operating effectively to mitigate different types of risk.

The guidelines for what types of risk mitigation measures are necessary will vary depending upon the type of SOC report and the scope of the audit itself. For example, a SOC 1 report focuses primarily on internal controls for financial reporting, and leverages the guidelines within the American Institute of Certified Public Accountants (AICPA) Statement on Standards for Attestation Agreements (SSAE 18). By contrast, a SOC 2 report focuses upon a broader set of internal controls that map to the AICPA’s Trust Services Criteria. The scope of a SOC 2 report is focused on security of the organization’s system, but the scope of the audit can expand to include additional criteria that include confidentiality, availability, processing integrity and privacy, as determined by the organization.

Challenges of a SOC Audit

One challenge when preparing for a SOC audit is that the guidelines and requirements enable an organization to address risk using several different strategies. Unlike other compliance assessments, SOC does not define the exact controls an organization must implement within their environment, leaving room for ambiguity.  SOC guidance enables an organization to use a risk-based approach to determine which controls need to be implemented to properly secure their environment. A SOC audit is a subjective evaluation of how well an organization meets the expectations defined by AICPA and must be performed by a licensed and independent CPA firm.

In addition, the types of controls implemented within an organization’s environment will differ depending on the industry and scope of services rendered.  For example, an organization whose primary service is payroll processing will have different policies and procedures when compared with an organization providing colocation services. Therefore, you must consider the nature of risks to the organization and how they align to the SOC 1 and SOC 2 reporting.

SOC Audit Checklist

Getting ready for an initial audit requires time and effort, but investing that time can assure a more seamless process for the first and any subsequent audits. Regardless of the type of audit being performed, there are actions every company can take well before the auditors arrive.

1. Review Auditing Standards

Ensure the organization’s personnel tasked with the SOC audit understand the expectations and time commitment involved. The AICPA does a good job detailing its security guidelines, auditing standards and requirements. Staying on top of any new compliance standards is also important.

2. Account for Organizational Changes

In today’s fast-moving economy, organizations are continually moving into unmapped territory and competing with new service offerings. These changes can shift the scope of their security posture and pose unseen risks that require implementing additional policy considerations and controls to address such risks. Organizations should regularly review and update their internal controls framework to ensure all potential risks are addressed.

3. Develop a Timeline and Assign Tasks

A SOC audit should never be a surprise to an organization. A detailed project plan, including milestones and identified process owners responsible for the tasks, should be in place to set the organization up for success. The timeline should be discussed with the auditors to ensure that the compliance and audit firm is also prepared to best assist the organization.

4. Review Prior Audits (if available)

If available, previous SOC reports — as well as other compliance reports (e.g. PCI ROC, ISO Certification) — can provide a helpful roadmap for identifying how an organization’s internal controls framework is designed and operating. If an auditor has identified an exception or issue with a particular process or control in the past, that process or control should be a priority to address ahead of the next audit.

5. Gather Relevant Data

Depending on the type of audit performed, auditors will need access to information related to various security controls and information policies. A Type 1 report evaluates the existing state of controls at a point in time to determine if controls are in place. A Type 2 report evaluates whether controls are in place, but it also evaluates the effectiveness of those controls over a specific time period. Collecting the relevant data and information ahead of time can make the audit process more efficient and enables the auditor to identify potential problems earlier.

Selecting the Right Auditing Firm

When evaluating a potential compliance and audit firm, the first question to ask is whether or not the company is licensed to conduct audits and issue SOC reports. While many vendors sell software packages that help an organization prepare and gather data for their audit, the vendor is often not able to conduct the SOC audit themselves. That means the organization will still need to find an auditing firm that can perform the actual audit, which slows down the entire project.

Any reputable auditing firm should be able to provide a SOC report that attests to its own security readiness. They should also have sufficient staff to handle audits efficiently and be able to respond to a client’s needs quickly to avoid setbacks and delays.

Elevate Your Compliance Readiness with ALIGN

A-LIGN is a technology-enabled security and compliance firm with more than 20 years of SOC reporting and comprehensive audit experience. Our strategic compliance approach identifies common elements across a broad range of regulatory frameworks to make it easier for companies to meet a variety of cybersecurity and privacy standards. With A-LIGN, there is no need to start from scratch ahead of every audit, because you will already have the right processes and controls in place for continuous compliance.

This article is Part One of a Four-part Series on the HITRUST Framework

Part One: 7 HITRUST Regulatory Factors to Consider for Healthcare 
Part Two: 7 HITRUST Regulatory Factors to Consider for Federal Compliance 
Part Three: 5 HITRUST Regulatory Factors to Consider for International and State-level Privacy Compliance
Part Four: 4 Miscellaneous HITRUST Regulatory Factors to Consider

When you think of HITRUST, you probably think of healthcare. After all, HITRUST was originally created as the “Health Information Trust Alliance.” However, over the past few years HITRUST has evolved to serve as an industry-agnostic common security framework – such that any company in any industry can now pursue a HITRUST CSF certification.

At its core, HITRUST is based on best practices from ISO/IEC 27001 and 27002, as well as more than 40 additional security and privacy regulations and standards, such as PCI, NIST and HIPAA. HITRUST considers these standards and regulations to be its authoritative sources.

In addition to these authoritative sources that serve as the foundation of HITRUST, there are also more than 20 regulatory factors that an organization could consider individually based on specific industry requirement – these are optional inclusions to an assessment.

Whether your organization is pursuing its first HITRUST certification or is returning for a recertification, it can be tricky to parse close to two dozen regulatory factors to determine if they should be included in an assessment. In this post, we will explore seven regulatory factors related to the healthcare industry. Future articles will focus on federal compliance, state and international privacy regulations, and the remaining miscellaneous regulations.

HIPAA

First Introduced in HITRUST 1.0 September 2009 as a baseline of the hitrust requirements, but under HITRUST 9.2 – January 2019, HIPAA became an optional regulatory factor

The Healthcare Information Portability and Assurance Act (HIPAA) was enacted by President Clinton in 1996, making it one of the oldest and most influential information security and privacy regulations in the United States. In fact, HIPAA serves as a precursor to HITRUST, since HITRUST was conceived as a certifiable standard for HIPAA compliance. However, as HITRUST has transitioned from a specific healthcare-related standard into a more industry-agnostic framework, the HIPAA regulations were moved into separate optional regulatory factors.

HIPAA requirements focus on the Security Rule, Privacy Rule and Breach Notification. Several healthcare providers and insurance companies require their business partners to demonstrate HIPAA compliance as a pre-requisite to working together, and the HITRUST CSF is a certifiable and widely accepted framework to demonstrate HIPAA compliance.

The A-LIGN Bottom Line: Any organization that processes, stores or exchanges healthcare data should include HIPAA in its HITRUST assessment.

CMS Minimum Security Requirements (High)

First Introduced in HITRUST 3.0 – December 2010

The Centers for Medicare & Medicaid Services (CMS) Information Security and Privacy Acceptable Risk Safeguards (ARS) sets forth a set of guidelines for its contractors known as the CMS Minimum Security Requirements (CMSR). These requirements share a common heritage with HITRUST, since the CMS requirements are based on NIST (among others) and regulated by HIPAA, which both serve as authoritative sources for HITRUST. The purpose of the CMSR is to protect Medicare & Medicaid information and information services, including CMS Sensitive Information.

Systems Security Levels (Low/Moderate/High) are defined within the appendix of the ARS manual. The Moderate and High impact levels require an independent Security Assessment; therefore, HITRUST has incorporated CMSR (High) as one of the optional regulatory factors to be included in a HITRUST assessment.

The A-LIGN Bottom Line: CMS contractors may be required to demonstrate compliance, but any organization that handles Medicare or Medicaid data should be advised to include CMSR High in its HITRUST assessment.

MARS-E Requirements

First Introduced in HITRUST 7.0 – January 2015

The Centers for Medicare & Medicaid Services (CMS) introduced its Minimum Acceptable Risk Standards for Exchanges (MARS-E) to address patient protection mandates and the Affordable Care Act. MARS-E applies to all “Administering Entities,” which are defined as state or federal exchanges and marketplaces, state Medicaid agencies, Children’s Health Insurance Program (CHIP) agencies, or state agencies administering the Basic Health Program. The purpose of MARS-E is to comply with the security and privacy standards and hitrust requirements of the Affordable Care Act.

The A-LIGN Bottom Line: MARS-E is primarily focused on the exchange of healthcare information related to Medicare and Medicaid. Whereas CMSR should be considered by any organization that handles this sort of healthcare information, MARS-E is more directly focused on the exchange of this information.

Joint Commission Accreditation (formerly JCAHO)

First Introduced in HITRUST 2.2 – September 2010

The Joint Commission Accreditation is a non-profit organization that accredits more than 22,000 healthcare programs across the United States. Many state governments recognize Joint Commission Accreditation as a licensing condition to receive Medicare and Medicaid reimbursements. In fact, from 1965 until 2010, the Joint Commission Accreditation was a legally recognized authority for hospital accreditation; however, the Medicare Improvements for Patients and Providers Act of 2008 (MIPPA) eliminated that distinction. Following that reversal, the Joint Commission Accreditation became subject to the requirements of CMS accreditation.

The A-LIGN Bottom Line: Joint Commission Accreditation is an optional accreditation that does not need to be included in a HITRUST assessment, unless an organization is contractually obligated. Additionally, Joint Commission Accreditation is much broader in scope than just cybersecurity and privacy, so including it in a HITRUST assessment could dramatically increase the scope of work.

EHNAC Accreditation

First Introduced in HITRUST 9.0 – September 2017

The Electronic Healthcare Network Accreditation Commission (EHNAC) is similar to the Joint Commission Accreditation because it is also a non-profit organization, but whereas the Joint Commission is focused on accrediting healthcare providers, EHNAC is focused on accrediting health information exchanges and other electronic health services, such as payments and prescriptions. EHNAC develops standards for health information exchanges, and it serves as the accrediting body for these standards.

The A-LIGN Bottom Line: Pursuing EHNAC Accreditation is an extraneous activity, unless an organization is contractually obligated. Organizations involved with health information exchanges may find EHNAC Accreditation worthwhile, but would typically pursue it independently of a HITRUST assessment.

Texas Health & Safety Code, Section 181 (TX HB 300)

First Introduced in HITRUST 5.0 – January 2013

The Texas House Bill 300 (TX HB 300) is a state-level healthcare regulation that is considered to be a more stringent version of HIPAA compliance, and section 181 deals specifically with Medical Records Privacy for residents of Texas. One of the primary differences between TX HB 300 and HIPAA is that TX HB 300 casts a much wider net in defining its covered entities. TX HB 300 includes any individual that possesses protected health information (PHI), even the academics, accountants, and lawyers that are precluded from HIPAA compliance. TX HB 300 introduces new standards for the handling of electronic health records (EHR), and it requires extensive, periodic employee training.

The A-LIGN Bottom Line: Any Organization (note extended definition of covered entity) that assembles, collects, analyzes, uses, evaluates, stores, or transmits PHI for a Texas resident should consider including this regulatory factor.

HITRUST De-ID Framework Requirement

First Introduced in HITRUST 8.0 – February 2016

The HITRUST De-Identification Framework was developed to provide a program and methodology for anonymizing data so that it can be used for the purpose of comparative effectiveness research (CER), Health Economics and Outcomes Research (HEOR), early detection of disease outbreaks, reduction of medical errors, and so forth.

The A-LIGN Bottom Line: Organizations should balance the risk vs the reward of de-identifying protected healthcare information, since the penalty for errors can be significant. As a result, most organizations avoid the process of transacting anonymized healthcare data. But for those organizations that are willing to take the risk, the HITRUST De-ID Framework Requirement is a worthwhile inclusion to a HITRUST CSF Assessment.

The A-LIGN Bottom Line: Organizations should balance the risk vs the reward of de-identifying protected healthcare information, since the penalty for errors can be significant. As a result, most organizations avoid the process of transacting anonymized healthcare data. But for those organizations that are willing to take the risk, the HITRUST De-ID Framework Requirement is a worthwhile inclusion to a HITRUST CSF Assessment.

Implement a Strategic Approach to HITRUST Compliance

The standardization of compliance regulations and the consolidation of audits are both tenets of a strategic compliance program. Adding the correct regulatory factors to a HITRUST assessment is a great way to start realizing the benefits of strategic compliance vs. handling each assessment individually. In fact, even the HITRUST mission statement seems to resonate with a strategic approach to compliance: One Framework, One Assessment, Globally.

UP NEXT: Federal Regulatory Factors – Part 2 of 4

Download our HITRUST checklist now!

Microsoft’s Supplier Security and Privacy Assurance Program (SSPA), formerly known as the Vendor Privacy Assurance Program, is an initiative designed to standardize and strengthen how Microsoft’s customer, partner, and employee information is handled by Microsoft vendors worldwide.

Compliance and Attestation

Organizations that are or want to become a Microsoft vendor must meet the requirements within the SSPA. This program requires that any vendor that collects, stores, or processes customer, partner, or employee information meet the reporting requirements.

All vendors must complete the annual Microsoft Personal Information (MPI) Inventory. Vendors are assigned an anniversary date where they will receive an email from Microsoft containing a hyperlink to the MPI Inventory. Depending on the type of data handled, per the inventory, the Microsoft SSPA Attestation reporting guidelines group vendors into three categories: high business impact, moderate business impact, and low business impact.

Low Business Impact

Low business impact organizations must complete the MPI Inventory within 30 days. Upon submission of the inventory, a data classification is assigned to the vendor.

Vendors handling data classified as having no personal information or low business impact require no further action. An anniversary date will be assigned based on the date of completion of the MPI Inventory, which will set the annual compliance cycle.

Moderate Business Impact

Moderate business impact data includes personally identifiable information (PII) that is not highly sensitive, such as (but not limited to):

• Name
• Address
• Email address
• Phone number
• IP address
• Racial information
• Ethnic information
• Political information
• Religious beliefs
• Sexual orientation
• Trade union membership
• Physical or mental health

After completing the MPI Inventory, all moderate business impact organizations must adhere to the Microsoft Vendor Data Protection Requirements (DPR) and are required to certify compliance to the DPR with a self-certification within 90 days of submission of the MPI Inventory during their second compliance cycle, and annually from that point on.

An anniversary date will be assigned based on the date of submission of the self-certification, which will set the annual compliance cycle.

High Business Impact

High business impact data includes the following, but is not limited to:

• Authentication/authorization credentials, such as private cryptographic keys
• Highly-sensitive PII, such as:
  • Financial transaction authorization data, such as credit card numbers
  • Financial profiles, such as consumer credit reports
  • Medical profiles, such as biometric identifiers

All high business impact organizations must also adhere to the DPR. Businesses that are considered high business impact must submit a letter of attestation from an approved third-party within 90 days of the submission of the annual MPI Inventory.

An approved third-party must be:

• A member in good standing with the American Institute of Certified Public Accountants (AICPA) or the International Federation of Accountants (IFAC)
• Qualified to conduct a Generally Accepted Privacy Principles (GAPP) assessment

Organizations that are high business impact must submit a letter of attestation after their third compliance cycle, and for all subsequent cycles. An anniversary date will be assigned based on the date of submission of the letter of attestation, which will set the annual compliance cycle.

Secure Your Summit

As a preferred assessor and approved third-party attestation body, A-LIGN has been vetted by Microsoft Procurement to perform a Supplier Security and Privacy Assurance (SSPA) assessment and empower your organization to meet SSPA requirements and conduct business with Microsoft.

If your high-impact organization requires a letter of attestation, our professionals can help you achieve compliance by assessing your organization’s controls, identifying gaps against SSPA requirements and completing your letter of attestation.

Let A-LIGN guide your journey from Information Security Management System (ISMS) to Privacy Information Management System (PIMS)

If ‎ISO/IEC 27001:2013 has been the gold standard for Information Security Management Systems (ISMS), then ISO/IEC 27701:2019 is the new gold standard for Privacy Information Management Systems (PIMS). ISO 27701 was developed to help organizations implement privacy controls against a certifiable framework to demonstrate a strong privacy program. Privacy has become a global zeitgeist with international and domestic privacy regulations driving the adoption of new privacy controls.

The General Data Protection Regulation (GDPR) has been driving international data privacy since it came into effect on May 25, 2018. The penalty for non-compliance is steep – €20 million or 4% of annual revenue. There have been dozens of fines in the past two years, including €50 million against Google and €99 million against Marriott.

Its home-grown cousin, the California Consumer Privacy Act (CCPA), came into effect for California in 2020 – enforcement began July 1. Time will tell how fiercely CCPA will be enforced, but if GDPR is any indication, then its advocates will be seeking to make an example out of companies that fail to comply. Case in point, Zoom has already been served a class action lawsuit for violating individuals’ CCPA privacy rights.

When privacy is such a premium, data controllers, data processors, and their partners have realized the value of demonstrating trust. Organizations want certification to prove they have done the hard work.

ISO 27701 is the first international privacy standard to provide a certification path for organizations to demonstrate their privacy systems and controls. ISO 27701 is a privacy extension to ISO 27001, which requires extending an ISMS into a PIMS. Compliance with privacy standards and regulations cannot be achieved without implementing appropriate technical and organizational security controls.

The Path to ISO 27701 Certification

To receive an ISO 27701 accredited certificate, organizations must either be ISO 27001 certified or undergo a series of initial audits conducted by a certification body. There are multiple parallels paths for ISO 27701 Certification, one for data controllers and one for data processors. Generally, a controller collects the data and directs it to be processed, whereas a processor processes the data for its controller. Controllers are assessed on their privacy notices, protections, principles, and processor requirements. Processors are assessed on their ability to limit processing, assist privacy protection, transfer disclosure, and subcontractor requirements. Additionally, both controllers and processors are required to demonstrate confidentiality agreements, risk analysis, oversight, training, processes, and records. Since ISO 27701 is an extension of ISO 27001, organizations should begin with a gap assessment and develop a plan to close the gap between their ISMS and their PIMS.

Consolidate Compliance with ISO 27701

ISO 27701 minimizes the burden of managing multiple privacy requirements through consolidation—a strategic approach to compliance. Consequently, organizations considering ISO 27701, should also consider where else they consolidate their compliance program, in an effort to conduct multiple audits at once.

A Strategic Partner in A-LIGN

A-LIGN enables organizations to elevate their strategic compliance initiatives with A-SCEND, its proprietary compliance management system that centralizes and streamlines workflows to eliminate duplicate work. As an ANAB accredited certification body, A-LIGN is one of a few companies that can issue an accredited ISO 27701 certification globally.

The world of compliance is filled with acronyms and abbreviations for some of its more complicated regulation systems and organizations. There is perhaps no better example than the long list of acronyms associated with federal compliance laws. Ensure you and your organization are up to speed on this important terminology by reviewing this list.

Federal Compliance Terms, A-Z

3PAO – Third-Party Assessment Organization

A Third-Party Assessment Organization (3PAO) is an organization that has been certified to help cloud service providers and government agencies meet FedRAMP compliance regulations. By utilizing FedRAMP approved templates, these organizations evaluate cloud-based providers’ systems to ensure transparency and consistency in data security strategies. Per the U.S. General Services Administration’s (GSA), a 3PAO must meet the following requirements:

1. Independence and quality management in accordance with International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 17020: 1998 standards.
2. Information assurance competence that includes experience with the Federal Information Security Management Act of 2002 (FISMA) and testing security controls.
3. Competence in the security assessment of cloud-based information systems.

ATO – Authority to Operate

As part of the Agency authorization process, a Cloud Service Provider (CSP) works directly with the Agency sponsor to review the cloud service’s security package. After the security assessment is completed, the head of the Agency—or their authorized designee—can grant an ATO. This process generally has four phases:

1. Partnership Establishment
2. Full Security Assessment
3. Authorization Process (during which the ATO status is approved)
4. Continuous Monitoring

CDI – Covered Defense Information

Covered Defense Information (CDI) is an umbrella term used to describe information that requires protection under DFARS Clause 252.204-7012. It is defined as unclassified Controlled Technical Information (CTI) or other information as described in the Controlled Unclassified Information (CUI) registry that requires safeguarding or dissemination controls. CDI will either be marked or otherwise identified in the contract and provided by DoD in support of the performance of the contract. Additionally, CDI may also be collected, developed, received, transmitted, used or stored by the contractor in the performance of the contract.

CSF – Cybersecurity Framework

A Cybersecurity Framework (CSF) is defined as “voluntary guidance, based on existing guidelines, and practices for organizations to better manage and reduce cybersecurity risk.” It should be organized, adaptable, repeatable and effective, to best ensure marginal risks to valuable company data and information. There are four common kinds of CSFs:

1. Payment Card Industry Data Security Standard (PCI DSS)
2. International Organization for Standardization (ISO 27001/27002)
3. CIS Critical Security Controls
4. NIST Framework

CSP – Cloud Service Provider

A Cloud Service Provider (CSP) is a company that offers some component of cloud computing to other businesses or individuals. CSPs make their offerings available as an on-demand, self-provisioning purchase or on a subscription basis. There are three types of CSPs:

1. Infrastructure as a Service (IaaS): In this model, the CSP delivers infrastructure components to an organization that would otherwise exist in an in-house data center. Examples include servers, storage and networking as well as the virtualization level, which the IaaS provider hosts in its own data center.
2. Software as a Service (SaaS): SaaS vendors offer an assortment of business technologies, including productivity suites, customer relationship management software, healthcare IT software and more.
3. Platform as a Service (PaaS): A PaaS service provider offers cloud infrastructure and services that users can access to perform various functions—this type of CSP is most commonly used in software development.

CUI – Controlled Unclassified Information

Controlled Unclassified Information (CUI) is defined as “information that requires safeguarding or dissemination controls pursuant to and consistent with applicable law, regulations and government-wide policies—but is not classified under Executive Order 13526 or the Atomic Energy Act.”

FedRAMP – Federal Risk and Authorization Management Program

The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization and continuous monitoring for cloud products and services.

FISMA – Federal Information Security Modernization Act of 2014

The Federal Information Security Modernization Act of 2014 (FISMA 2014) is legislation that directs federal government agencies to implement a cybersecurity program that includes independent assessments as well as NIST SP 800-37, Revision 2. FISMA assigns responsibilities to a variety of agencies to ensure the security of data in the federal government. The National Institute of Standards and Technology (NIST) outlines the nine steps towards compliance under FISMA:

1. Categorize the information to be protected.
2. Select minimum baseline controls.
3. Refine controls using a risk assessment procedure.
4. Document the controls in the system security plan.
5. Implement security controls in appropriate information systems.
6. Assess the effectiveness of the security controls once they’ve been implemented.
7. Determine agency-level risk to the mission or business case.
8. Authorize the information system for processing.
9. Monitor the security controls on a continuous basis.

JAB – Joint Authorization Board

The Joint Authorization Board (JAB) is the primary governance and decision-making body for the FedRAMP program. The JAB reviews and provides joint provisional security authorizations on cloud solutions using a standardized baseline approach. Its members include Chief Information Officers from the Department of Defense, the Department of Homeland Security and the General Services Administration. The defined duties for the JAB include:

1. Define FedRAMP security and authorization requirements.
2. Approve accreditation criteria for third-party assessment organizations (3PAO).
3. Establish a priority queue for authorization package reviews.
4. Review FedRAMP authorization packages.
5. Grant joint provisional authorizations.
6. Ensure that provisional authorizations are reviewed and updated regularly.

NIST 800-171 – National Institute of Standards and Technology

The National Institute of Standards in Technology is a physical science laboratory and a non-regulatory agency of the Department of Commerce. Founded in 1901, the agency was established to remove a second-rate measurement infrastructure that was causing the country to lag behind the industrial competitiveness of the UK, Germany and other economic rivals. Today, NIST measurements support the most innovative technology being developed ranging from microscopic medical monitoring devices to communication systems that span the globe.

One such measurement is the National Institute of Standards and Technology Special Publication 800-171, which governs Controlled Unclassified Information (CUI) in Non-Federal Information Systems and Organizations. Essentially, this standard defines how to safeguard and distribute material deemed sensitive, though not classified. Developed in a response to the passage of FISMA in 2003, NIST 800-171’s intent was to improve cybersecurity as the industry and the risks surrounding it continued to evolve.

P-ATO – Provisional Authorization to Operate

According to the FedRAMP website, a Provisional Authority to Operate (P-ATO) is permission given to an organization to operate at the Moderate impact level by the FedRAMP Joint Authorization Board (JAB). Essentially, a P-ATO is a preauthorization for an organization that then allows in-house monitoring and implementation of a cybersecurity system.

PMO – Program Management Office

A Program Management Office (PMO) is a group—either internal or external—that sets, maintains and ensures standards for project management across an organization. Their other responsibilities include ensuring that company procedures, practices and operations run smoothly—on time, on budget and all in the same way.

RMF – Risk Management Framework

Developed by NIST, a Risk Management Framework (RMF) is a set of information security policies and standards for organizations. A well-structured RMF provides an effective framework to facilitate decision-making to select appropriate security controls. There are seven recommended steps for implementing an RMF:

1. Prepare: The organization must examine its current security measures and identify areas of potential risk or weakness.
2. Categorize: Classify and label the information processed, stored and shared, as well as all of the systems the organization relies on.
3. Select: Review the categorization and select baseline security controls. Revise and add to the security control baseline as necessary, based on organization assessment of risk and local conditions.
4. Implement: Instill the security controls and integrate with legacy systems. Document how the controls are arranged within the system and their effects on the overall environment.
5. Assess: Evaluate the security controls to determine their quality and effectiveness.
6. Authorize: Top management tests and approves the secured system passed on the accepted risk appetite to operations and assets. Management should also consider the system’s overall impact on individuals and other organizations. Once the level of remaining risk has been identified, the framework can either be authorized or subjected to additional revisions.
7. Monitor: An organization should develop an ongoing monitoring and assessment schedule for the security controls. A thorough documentation of results is a must-have.

SSP – System Security Plan

A System Security Plan (SSP) documents the controls that have been selected to moderate the risk of a system. These controls are determined by the Risk Analysis and the FIPS 199. Federal systems—defined as any systems that are funded by federal money—fall into either a Low, Moderate or High category, per NIST’s guidelines. An SSP provides information regarding the system owner, name of the system and lists the security controls selected for the system. Each control listing includes a detailed description that allows the system owner or auditor to confirm the effectiveness of that control.

How A-LIGN Can Help

As a full-service security, compliance and privacy firm, A-LIGN provides organizations a variety of federal assessment services. Our team of assessors have experience in CMMC, FISMA, FedRAMP and NIST 800-171 assessments, and can help you determine which is vital for your organization. Together, we can determine the security requirements your organization needs for an ATO, as well as develop a holistic plan of action to protect your CDI and CUI.

Understanding the purpose and examination process of a SOC 2 audit an be confusing for first-time users and experienced customers alike. A simple Google search can give you the basics of a SOC 2 audit, but that generalized knowledge is only the beginning.

A-LIGN has taken numerous looks at what a SOC 2 is, what kind of organizations need one, and why this audit is important for security measures that meet today’s world’s exacting standards.

In our whitepaper, The SOC 2 Examination Process, we take an in-depth look at the SOC 2 audit and address topics including:

• Frequently asked questions regarding SOC 2
• The differences between a Type 1 SOC 2 audit and a Type 2 SOC 2 audit
• Why do organizations often benefit from a readiness assessment?
• The steps involved in a SOC 2 audit

The Types of SOC 2 Audits

• SOC 2 Readiness: Our readiness assessment provides your organization with the tools and confidence to prepare for the route ahead with the help of our experienced auditors.
• SOC 2 Type 1: A Type 1 report which delivers a description of your organization’s system and its ability to meet the relevant criteria set by the Trust Services Criteria at a specific date in time.
• SOC 2 Type 2: Type 2 reports include a description of your organization’s system along with the results of the auditor’s tests, as related to the Trust Services Criteria over a period of time. In addition, a Type 2 report gives a historical view of an organization’s environment to determine if the organization’s internal controls are designed and operating effectively

On September 3, 2019 HITRUST announced that they will be updating the HITRUST PRISMA Weights (HAA 2019-007) and the Scoring Rubrics (HAA 2019-009). These new guidelines will go into effect for any HITRUST certifications submitted and accepted on December 31, 2019 or later.

(more…)

Managed service providers (MSPs) provide a valuable service by enabling companies of all sizes to outsource their key information technology processes. Many of those companies who look to engage an MSP ask whether a SOC 1 or SOC 2 Examination has been completed to assess the MSP’s security posture.

Not sure where to start when a prospective customer asks you about a SOC report? Below are our top tips for determining if your MSP should complete a SOC 1 or a SOC 2 Examination – or both.

How Do I Know if My MSP Needs a SOC 1 or SOC 2?

Often, your clients will let you know which assessment they want your MSP to undergo. They might request a specific examination, such as SOC 1 or SOC 2, or they may be a little vaguer in their direction and ask for a third-party security audit to be completed by a CPA firm. If they’re less certain on which compliance assessment to complete, our SOC experts can review your MSP and its business practices to help determine the appropriate audit to undergo. Depending on the nature of your MSP, you might benefit from undergoing completing multiple compliance assessments concurrently in lieu of the overlap in process and requirements.

Who Should Get a SOC 1 Examination:

A SOC 1 audit is the ideal audit for MSPs that handle, process, store or transmit financial information. These industries may include:

• Payroll Processors
  • A payroll processor distributes an organization’s payroll funds amongst its employees per the terms of the employer’s agreements as a service. The services of a payroll processor directly impact the organization’s financial reporting, making a SOC 1 audit critically important.
• Collections Organizations
  • A collections firm collects money on behalf of another company as a service and records and transfers those funds back, reconciling the organization’s financial statements. Because of their direct impact on financial reporting, SOC 1 audits are vital for collections organizations.
• Data Centers
  • A data center allows systems and software to operate with maximum availability as a service for other firms. If those systems or software are used for functional finance transactions, then the loss of availability could impact those transactions and therefore impact financial reporting.
• SaaS MSPs
  • A software-as-a-service (SaaS) that offers a cloud service to an organization could be processing financial statements or reporting on statements that record to the general ledger, therefore impact financial reporting.

Who Should Get a SOC 2 Examination:

Organizations of all sizes and industries can benefit from a SOC 2 Examination, as the audit can be performed for an organization that provides a variety of services to its customers. A SOC 2 report highlights the controls in place that protect and secure an organization’s system or services used by its customers. Unlike a SOC 1, the scope of a SOC 2 Examination extends beyond the systems that have a financial impact, reaching all systems and tools used in support of the organization’s system or services. This assurance in the security of the environment can be provided thanks to the requirements within a SOC 2 Examination, known as the Trust Services Criteria (TSC). The TSC are based on upon the American Institute of Certified Public Accountants and consist of five categories:

• Common Criteria/Security (required)
• Availability (optional)
• Processing Integrity (optional)
• Confidentiality (optional)
• Privacy (optional)

MSPs that could benefit the most from SOC 2 Examinations include:

• Any Service Organization
  • Generally speaking, any MSP providing a service to a business, client or person should have a SOC 2 performed.
• Data Centers
  • A data center allows systems and software to operate with maximum availability as a service for other firms. Because of the critical role that data centers play, availability and physical security of the system is extremely important to the clients purchasing the infrastructure or platform. To confirm a certain degree of availability, a SOC 2 is often requested or recommended.
• SaaS MSPs
  • A cloud-based SaaS that is managed and hosted by a third party should complete a SOC 2 Examination to provide assurance on the security posture surrounding the in-scope system or service.

Read more: Leveraging a SOC 2 Examination to Differentiate Your MSP

Should Your MSP Conduct a SOC 1 and SOC 2?

As you may have noticed, some industries that MSPs serve recommend the completion of both a SOC 1 and SOC 2 Examination. Because the customer audience and value gained for a SOC 1 and a SOC 2 audit differ, it is often worth completing both a SOC 1 and SOC 2 Examination concurrently – especially considering a majority of the evidence and testing used in a SOC 1 can also be leveraged in the completion of a SOC 2 Examination. A-LIGN’s SOC experts will review the services offered to customers by your MSP in order to determine the best solution for you.

How A-LIGN Can Help

As customers begin to enhance their vendor management practices to secure their information, requests for compliance reports such as a SOC 1 or SOC 2 report will become more and more frequent. Working with a compliance service provider like A-LIGN, who has certified compliance professionals with extensive experience performing SOC 1 and SOC 2 audits, can set you on the right path in building credibility and trust with your customers. Moreover, A-LIGN is well-versed in meeting the requirements of a broad range of compliance standards and security frameworks including SOC, PCI, ISO, GDPR, FISMA and NIST to help you meet all compliance needs.