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.

What is ISO 27701?

The ISO/IEC 27701:2019 standard was published on August 6, 2019, and provides the requirements and guidance for establishing, implementing, maintaining and continually improving a Privacy Information Management System (PIMS) as an extension of ISO/IEC 27001:2013 and ISO/IEC 27002:2013. This extension replaces the development standard ISO 27552.

This extension will be most relevant for personally identifiable information (PII) controllers and processors but can be used by organizations of any kind, size, and location. ISO 27701 allows these organizations to improve their PIMS by enhancing their Information Security Management System (ISMS). Since ISO 27701 is an extension of the ISO 27001 standard, there will not be a stand-alone certification for ISO 27701.

As privacy concerns and requirements continue to increase globally, the addition of ISO 27701 to ISO 27001 certifications will become increasingly important to organizations.

ISO 27701 Standard Structure:

• Clauses 5 and 6: Provide additional specific guidelines related to privacy for ISO 27001 and ISO 27002
• Clause 7: Provides 31 controls that will be relevant to PII controllers and includes the following controls objectives:
  • 7.2 Conditions for collection and processing: To determine and document the processing is lawful, with legal basis as per applicable jurisdictions, and with clearly defined and legitimate purposes
  • 7.3 Obligations to PII Principles: To ensure that PII principles are provided with appropriate information about the processing of their PII and to meet any other applicable obligations to PII principles related to the processing of their PII
  • 7.4 Privacy by design and privacy by default: To ensure that processes and systems are designed such that the collection and processing (including use, disclosure, retention, transmission and disposal) are limited to what is necessary for the identified purpose
  • 7.5 PII sharing, transfer, and disclosure: To determine whether and document when PII is shared, transferred to other jurisdictions or third parties and/or disclosed in accordance with applicable obligations
• Clause 8: Provides 18 controls that will be relevant to PII processors and includes the following control objectives:
  • 8.2 Conditions for collection and processing: To determine and document that processing is lawful, with legal bases as per applicable jurisdictions, and with clearly defined and legitimate purposes
  • 8.3 Obligations to PII principals: To ensure that PII principals are provided with the appropriate information about the processing of their PII, and to meet any other applicable obligations to PII principals related to the processing of their PII
  • 8.4 Privacy by design and privacy by default: To ensure that processes and systems are designed such that the collection and processing of PII (including use, disclosure, retention, transmission and disposal) are limited to what is necessary for the identified purpose
  • 8.5 PII sharing, transfer, and disclosure: To determine whether and document when PII is shared, transferred to other jurisdictions or third parties and/or disclosed in accordance with applicable obligations
• Annex A & Annex B: PIMS specific control objectives and controls for PII controllers and PII processors respectively
• Annex F: Informal guidance on practical applications of ISO 27701

Impact of ISO 27701:

A primary operational impact of ISO 27701 is the inclusion of privacy concepts and, in particular, the incorporation of many articles from the General Data Protection Regulation (GDPR) into the ISO framework. Similar to the focus of the GDPR on the controller and processors processing of personal data, ISO 27701 places the responsibility of compliance on the PII controllers (the person or agency who determines the purposes and means of the processing of personal data) and the PII processors (the person or agency who processes personal data on behalf of the controller).

Requirements applicable to and impacting both PII controllers and processors:

• Security: Physical, operational and administrative controls are required to protect PII.
• Confidentiality and Integrity: A confidentiality agreement must be executed by any individuals authorized to access PII and the integrity of the PII data must be maintained.
• Risk Assessments: To identify risks associated with new processing of PII or changes to the existing processing of PII, a privacy impact assessment must be conducted.
• Roles and Responsibilities: An individual should be appointed to develop, implement, monitor, and maintain the organization’s governance and privacy program.
• Training: Any personnel that will have access to PII will be required to complete privacy awareness training.
• Incident Management: Policies and procedures need to be established and adopted to respond to and document any incidents, including but not limited to data breaches.
• Records of Processing: Processing activities involving PII, including transfers and disclosures, must be documented and maintained by organizations.
• Transmission of PII Data: Controls must be implemented to govern the transmission of PII data.

Controller-Specific Requirements:

• PII Principals Notice: A privacy policy detailing the collection, use and processing of PII must be provided to the PII principals.
• PII Principal Rights: Mechanisms must be in place to accommodate individuals’ right to access, correct, erase, or object to and restrict the processing of their PII, among others.
• Processor Contract Requirements: Written contracts must be in place with their processors that address specific items, such as protecting PII, limiting processing to the specific purpose for which the PII was collected, and providing notification for breaches of PII.
• Data Minimization and Purpose Limitation: Limitations shall be placed on the PII collected to only include that which is relevant, proportional and necessary to the identified purpose, and limits the processing of PII to the purpose identified.

Processor-Specific Requirements:

• Processing Limitation: Processing of PII can only occur on the documented instructions of the controller or processor (depending on the role of the customer).
• Engagement of Subcontractors: In order to use a subcontractor to process PII, a written contract is required with the subcontractor authorizing the processing of PII and ensuring the implementation of appropriate controls.
• Infringing Instruction: Processing instructions received that are perceived to infringe on applicable legislation and/or regulation must be communicated to the customer.
• Assistance with Customer’s Obligations: Measures must be implemented that assist the customer in complying with the right of individuals.

Benefits of ISO 27701:

• Streamline compliance obligations for ISO 27001 and the GDPR by integrating privacy into your organizations ISMS
• Surpass the competition and attract new customers with a demonstration of increased security and privacy in your organization
• Maintain peace of mind for your current customers that their PII is protected
• Gain a better understanding of the Privacy Information Management Systems (PIMS) implementation process
• Avoid potential fines as the enforcement of privacy protection continues to increase