A Guide to IT Jargon for Your Contracts

We’ve all seen it. Your organization has a contract in place with a key customer, but your obligations don’t necessarily make sense to the people responsible for achieving them. This is especially common with IT-related obligations, and is typically caused by the volume of verbiage addressing IT topics and a lack of understanding of that jargon by legal and finance leadership.

Ideally, IT personnel would review technology-related statements before each contract is signed. A more realistic alternative is to provide a list of statements that should be considered carefully, or avoided entirely.

As a starting point for your organization, here is a list of common problematic themes we observe in contracts of clients that are service providers:

Frequency of events

Finance and IT are accustomed to monthly and quarterly processes, but sometimes it makes sense to complete a process with a different frequency. You should weight the frequency of executing a process against the benefit to your service offering or data security. For example:

• According to generally accepted practice, penetration tests should be conducted at least annually, or after significant changes, and not quarterly unless the increased frequency adds value for the organization or its customers.
• The timing of patching or remediation of identified vulnerabilities should be based on severity of the issue and availability of a fix, and not on a blanket policy of 24 hours from identification.

Specified reports

From SOC to PCI to ISO, there are many types of attestation reports available. The key is to know which reports apply to your organization and provide the most coverage for your clients.

• If you are providing services that support customers’ payment card transactions, you likely will need to provide the Payment Card Industry (PCI) Attestation of Compliance (AOC) to your clients instead of your Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ), which are sometimes included in contracts.
• Similarly, for System and Organization Controls (SOC) reports it’s important to understand if you need to provide a SOC 1 or SOC 2, and if a point in time Type 1 is acceptable, or if you need to address controls in place over the period with a Type 2. It is also important to understand what aspects of your services are relevant to report upon.

Who performs specific functions or services?

It is important to understand what levels of assurance are required as there are different providers for different types of assurance. Not all assessors perform all services, and there could be independence concerns or conflicts of interest that require you to use multiple firms.

• While many PCI Qualified Security Assessor (QSA) firms have a security consulting group that can perform penetration testing, a QSA firm is not required to perform the pen test even when the penetration test is being conducted to comply with the PCI Data Security Standard (DSS).
• Most security standards require periodic vulnerability scans. It would be prudent to ensure that the scanning vendor is well qualified to meet the needs of your organization. However, PCI specifically requires that the scanning vendor be an Approved Scanning Vendor (ASV). So, if you have customers requiring your organization to be PCI compliant, you will need to ensure that the scanning vendor you choose is a PCI ASV.
• SOC reports can only be conducted by registered CPA firms. There are some CPA firms who are also QSAs, but not many. If you have both PCI and SOC requirements, finding an audit firm that is both a QSA and CPA firm can lead to synergies and efficiencies in getting through both assessments.

Vague language

This one can be a little trickier. There are times where vagaries may be beneficial if your customer is flexible. But, vague language can lead to painful misunderstandings, especially with demanding customers. While not an exhaustive list, here are some circumstances we often see:

• Contractual requests for penetration testing: This term means different things to different people. First, confirm the request is accurate so that you can incorporate specifics about objectives and expected scope if a penetration test is truly required.
• Requirement for a SOC report without specifying what kind: Is it a SOC 1 or a SOC 2? If it’s a SOC 2, are there specific Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity and Privacy) that the customer wants to address? Vague language around SOC reporting leaves a lot to interpretation and you want to make sure the expectations of the customer and the service provider are properly aligned.

Right to audit

The Right to Audit clause is common in service provider contracts. But, as attestation reports become an increasingly frequent requirement, it’s important to revisit this clause and evaluate its necessity. Key considerations would be:

• Do the available attestation reports address the audit needs of all of your customers? Most customers will prefer to receive an attestation report, such as a SOC report or PCI AOC, instead of utilizing their staff to independently audit a service provider. This in turn may reduce the audit burden on the service provider, allowing them to use their resources more efficiently.
• Are the agreed frequencies of audits reasonable given the services provided? A prescribed frequency is important to ensure that customer audit procedures support the customer’s needs without adding undue burden on the service provider. For example, if a customer wants to perform procedures to rely on internal controls, perhaps the frequency should align with the annual audit requirement.
• Is the required access appropriate if the contract stipulates specific access levels? For instance, make sure the contract does not specify full access if read-only access is sufficient to obtain audit information.

Insurance

Cyber insurance is becoming increasingly common, and as such, is becoming a more frequent contractual requirement being placed on service providers by their customers. The key here is to ensure that any contractual coverage requirements are reasonable for your organization and customers and ensure that there aren’t any meaningful coverage exclusions that would create a violation of the contractual terms. We recommend that you review cyber policy-related contractual requirements with your insurance broker as a standard procedure in the contracting process.

There are many nuanced requirements across various industries and business models; this list is by no means exhaustive and is not intended to take the place of the opinion of your organization’s legal counsel. However, this may serve as a starting point for your own IT organization to develop a “cheat sheet” of sorts to help your Legal and Finance leadership identify appropriate IT considerations for contracts that can be executed in an attainable and valuable way.

We welcome you to contact Weaver’s IT advisory team to talk through additional opportunities to support your organization’s goals especially as you look to improve internal controls and processes, assess your security and privacy standards and increase the value of your IT organization to your internal and external stakeholders.

Authored by David Friedenberg, CISA, CRISC, CISSP, PCIP, QSA.

©2020