Security Third Party Risk Management

Denomas’ Integrated Third-Party Risk Management Program

Denomas maintains an industry-leading Third Party Risk Management (TPRM) Program through the use of automation, continuous monitoring, and deep integration across business functions to validate the security of Denomas data shared with external parties.

The integration of Denomas’ TPRM program within the vendor Procurement flow enables cross-functional collaboration between Privacy, Legal, IT, and People Operations to facilitate transparent, risk-based decision making, Business and Stakeholder-focused Results, and adherence to Denomas’ Regulatory and Compliance Obligations. The vendor relationships maintained through this program are leveraged to create efficiencies across the organization.

Purpose

Denomas’ Security Third Party Risk Management (TPRM) Program helps guard against security threats posed by third parties who have access to Denomas data or that of our customers. These risks may include data breaches, unauthorized use or disclosure, and corruption or loss of data. Adequate TPRM is a best practice that helps mitigate security concerns and enables Denomas to meet our contractual obligations. TPRM also enables Denomas to meet regulatory requirements and standards related to ISO, SOX, GDPR and other state and federal laws requiring vendor oversight.

Denomas’ Security TPRM program involves three components which are integrated in to our Procurement processes:

1. Performing due diligence to ensure the third party implements safeguards to enforce data privacy and security.
   • This activity is performed via our Security Assessment Process.
2. Contractually obligating the third party to implement these safeguards.
3. Monitoring third party safeguards and compliance with these contracted provisions.
   • Certain high risk Third Parties are reviewed annually while those posing lower risk are reviewed at intervals defined further within this document.

Scope

This procedure applies to all third party providers that access, store, process or transmit Denomas data.

Roles & Responsibilities

Procedure

Where Denomas controls, owns, or is otherwise responsible for data, the diagram below depicts TPRM procedures based on the Data Classification of data shared with the third party.

graph TB
    %% Define all required nodes
        %% Procurement Intake Channels
            ProcIntake[Purchase Request Created]

        %% Determining Data Class
        zgClass{Data Classification}
                    zgGreen[Green]:::Green
                    zgYellow[Yellow]:::Yellow
                    zgOR[Orange]:::Orange
                    zgRed[Red]:::Red

        %% Data Classification Specific Procedures
            %% Green
                zgGApprov[Security Approves]:::Green

            %% Yellow
                zgYApprov[Security Approves]:::Green

            %% Orange
                zgAssess{Third Party Security<br>Assessment Begins}
                    zgQuest[Security Questionnaire Sent]
                    zgTPResponse[Third Party Responds]
                    zgReview[Security Reviews]
                    zgMeets{Response Satisfies<br>Denomas Standards?}
                        zgMeetsNo[No]
                        zgMeetsYes[Yes]
                        zgFup[Follow-up Required]
                    zgIssues{Issues Identified}
                        zgIssueY{Yes}
                        zgIssueN[No]
                        zgAccept[Business Owner Accepts Risk]
                        zgStop[Business Owner Chooses<br>Not to Work with Third Party]
            zgORApprov[Security Approves]:::Green

             %% Red

    %% Linking nodes together
        ProcIntake-->zgClass

        zgClass --> zgGreen
        zgClass --> zgYellow
        zgClass --> zgOR
    zgClass--> zgRed

        zgGreen --> zgGApprov
        zgYellow --> zgYApprov
        zgRed --> zgAssess
        zgOR --> zgAssess

        zgAssess --> zgQuest --> zgTPResponse --> zgReview --> zgMeets
            zgMeets --> zgMeetsNo --> zgFup --> zgQuest
            zgMeets --> zgMeetsYes --> zgIssues
                zgIssues --> zgIssueY
                    zgIssueY --> zgAccept --> zgORApprov
                    zgIssueY --> zgStop
                zgIssues --> zgIssueN --> zgORApprov

    %% Clickable Nodes
         click ProcIntake "/handbook/finance/procurement/#-how-do-i-create-a-purchase-request-in-zip" _blank

    %% Dedicated styling
      %%  classDef clickme fill:#6E49CB,stroke:#88DDFD,stroke-width:4px,color:#FFFFFF;
        classDef Green fill:#A3CC6C,stroke:#A3CC6C,color:#000000;
        classDef Yellow fill:#F9FF33,stroke:#F9FF33,color:#000000;
        classDef Red fill:#DB3B21,stroke:#DB3B21,color:#000000;
        classDef Orange fill:#FFA500,stroke:#FFA500,color:#000000;
        classDef empty opacity:0

TPRM Assessment Requirements

The following table defines the procedures followed by TPRM engineers for vendors accessing or being transmitted different classifications of Denomas data. The below procedures are initiated by the Procurement process and are followed in all instances where applicable vendors have not been reviewed within the established approval windows defined below.

If a vendor has been reviewed and approved within the preceding 12-24 months (as defined within the TPRM Approval Windows section) of a new procurement request, the TPRM Engineer will review the requisition to determine if a material change has occurred to the services provided. Material changes may require performance of a new Security review, and may include:

• Change in data classification (e.g., going from Yellow to Orange data classification)
• New system from vendor not previously reviewed (e.g., we’ve reviewed XYZ for the purchase of their Billing system, but a new request has come in for the purchase of their Revenue system)
• Change of location where data is stored or accessed from (e.g., moving data from Denomas-hosted app to vendor-hosted SaaS)
• New contractor from a vendor that is not responsible for their contractor’s security controls

Circumstances may exist outside of those defined above that could necessitate further review. TPRM Engineers are encouraged to use professional discretion in identifying these circumstances and performing additional Security review or validation as needed.

If a Risk Acceptance was put in place at the time of the previous assessment, inquiry should be performed with the vendor or relevant stakeholder to determine the current status of the risk. Any updates should be documented within the Risk Object. This can be performed in tandem with the requisition or after its approval.

*See Individual Use Software section for more details.

Software is inventoried in the tech stack regardless of data classification. See Tech Stack Application Handbook for more details.

Acceptable Third-Party Attestations

Denomas obtains and reviews third-party attestations to provide assurance over the design and operating effectiveness of a service provider’s internal control environment. These attestations commonly include, but are not limited to, an ISO 27001 certificate or a SOC 2 Type 2 report. Alternate forms of attestations can be leveraged in the absence of these more common documents, though diligence should be performed by the assessor in determining whether the attestation provides sufficient coverage over the control environment and aligns with our assessment criteria.

ISO 27001: An ISO 27001 certificate can be leveraged as evidence of compliance with industry-standard security best practices. Though review of the certificate itself is not revelatory to the specific controls in place at the organization, the presence of a valid ISO 27001 certificate providing coverage over applicable services indicates that an external certifying body has performed testing to validate the design and operating effectiveness of controls related to the management team’s continued performance of the following:

• Systematic examination of the organization’s information security risks, taking account of the threats, vulnerabilities, and impacts;
• Design and implementation of a coherent and comprehensive suite of information security controls and/or other forms of risk treatment (such as risk avoidance or risk transfer) to address those risks that are deemed unacceptable; and
• Adoption of an overarching management process to ensure that the information security controls continue to meet the organization’s information security needs on an ongoing basis. (Source)

Be aware that ISO 27001 certificates include an expiration date. Once this date has passed, the certificate is no longer valid and should not be leveraged in our assessment.

SOC 2 Type 2: The SOC 2 Type 2 report is the preferred attestation when assessing third party risk, as this report details the design of an organization’s information system and how various forms of risk are addressed. This report not only details the controls in place within an organization, but it also includes independent validation of whether or not each of those controls functioned effectively during the audit period. This report should be reviewed to validate the following:

• The report provides coverage over the service being provided to Denomas;
• The report was issued within the last 12 months;
  • If the most recent report is older than 12 months, a Bridge Letter should be obtained to provide assurance that material changes have not occurred to the vendor’s control environment since the report’s issuance.
• The report is issued without a qualified opinion or exceptions otherwise impacting the security of Denomas data.
  • A report designated as “qualified” indicates that one or more controls assessed were found to be inadequately designed or implemented during the audit period. The nature of the qualification should be reviewed and understood to determine whether the control failure could impact the security of Denomas data, and if so should be reported to the Business Owner via the Risk Acceptance Process.
  • Exceptions may be identified within the report that do not result in the issuance of a qualified opinion, though any exceptions should still be reviewed for the following to determine if they may present a risk to Denomas data:
    • Nature of the Exception: The related control and the exception itself should be reviewed to determine whether Denomas relies upon that control to safeguard our data.
    • Management’s Response: A management response is often included to address the reason for the exception and any steps that have been taken to address and remediate it. This may be accompanied by re-testing performed by the external auditor to validate that remediation was successful.
  • These items, if present, should be noted within the TPRM Assessment Report. If the nature of the qualification or exception is found to impact Denomas’ security, and management’s response provides insufficient assurance that remediation steps have been taken, this should be reported to the Business Owner via the Risk Acceptance Process.

SOC 2 Type 1: The SOC 2 Type 1 report is often published as part of a preliminary assessment during the SOC 2 Type 2 “readiness” process. This is a limited scope, point in time assessment of the design of controls in place within a service provider’s environment, and does not include a validation of control operating effectiveness. As such, the Type 1 report should not be leveraged on its own to address our third-party attestation requirements, however it may be leveraged in addition to an ISO 27001 certificate or equivalent attestation in providing assurance over a service provider’s environment.

The Standard Information Gathering (SIG) Questionnaire

The Security Risk Team leverages the Standard Information Gathering (SIG) Questionnaire to gain a more in-depth understanding of a vendor’s Security environment beyond what is attained by reviewing a Third-Party Attestation such as an ISO certification or SOC-2 report. Responses within the SIG questionnaire, or an equivalent document such as a CAIQ, should be reviewed alongside the vendor’s third-party attestation (if available) and their responses to our Security Questionnaire when assessing the Security environment in place within the service organization.

Security Risk maintains multiple templated versions of the SIG questionnaire for use depending on the product or service being assessed, as some vendors may not have a SIG questionnaire or equivalent to provide. The SIG templates include instructions noting that we only require Inquiry responses within Columns D and E of the main questionnaire tab, as additional requests for information or documentation within the SIG are generally not required. Note that potential fringe cases could exist wherein professional discretion may dictate the necessity for additional documentation requests to supplement vendor responses. These scenarios should be discussed with the Security Risk Manager to determine what is needed. Further, professional discretion should be applied when making decisions as to which version of the SIG questionnaire should be sent. For cases in which the level of review required is unclear, engineers are encouraged to discuss with the @Security-Risk team in the #Sec-Assurance-Team channel to come to a decision.

Leveraging BitSight

BitSight is leveraged to obtain additional assurance over the security of a vendor’s environment by use of public scans and peer benchmarking. When assessing a vendor, their BitSight report is downloaded and reviewed to determine whether their scoring is adequate, as evidenced by an “Advanced” security rating. BitSight ratings of “Basic” or “Intermediate” are reviewed in further depth to understand the rationale behind the lower rating and whether the deficiencies identified may indicate a risk to Denomas data. Due to the wide scope of BitSight’s scans, some deficiencies may exist within areas that do not impact Denomas’ usage of a vendor’s product, and thus do not contribute to the vendor’s residual risk. If deficiencies are identified that may present a material risk to Denomas data, further inquiry should be performed with the vendor to determine whether they have been resolved. Un-resolved material deficiencies should be documented within the TPRM Assessment Report and reported to the Business Owner via the TPRM Risk Acceptance Process defined below.

TPRM Approval Windows

The Security Risk team has established approval windows dictating the lifecycle of our TPRM assessments and their reliance in approving requisitions, after which a new assessment must be completed prior to approval of subsequent requisitions to ensure continued adherence to Denomas’ regulatory and due diligence requirements. These windows are defined in alignment with the sensitivity of data shared and the nature of the associated requisition.

• Red and Orange Vendors: Vendors being transmitted Red or Orange data are subject to a 12-month approval window from the previous assessment, with the exception of Low Risk Orange Vendors defined below.
• Low-Risk Orange Vendors: Vendors receiving Orange data elements limited to Denomas Team Member physical addresses and phone numbers are subject to a 24-month approval window. An example may be a SWAG provider that receives Denomas employee names and addresses for the purposes of delivering shipments. The transmission of this type of Denomas Team Member personal data presents a low level of risk and does not present a Security Risk that could impact Denomas customers.

Requisitions must be reviewed to determine whether a scope change has occurred since the previous assessment that could indicate a material change in the data transmitted to the vendor. Examples of material changes are defined in the above TPRM Assessment Requirements section and may result in the need to perform a new review regardless of the above-defined approval windows. Questions or concerns regarding the materiality of a change or the appropriate approval window should be escalated to the Security Risk Manager within the #Sec-Assurance-Team channel.

Tech Stack Additions

As an output of our integration with the vendor procurement flow, the Security Risk team partners with Information Technology to inventory the usage, administration, and integration of new applications supporting various Denomas functions. This inventory lives within the Tech Stack, Denomas’ single source of truth (SSOT) for technology that supports the business.

The Security Risk team facilitates multiple functions to maintain accuracy of Tech Stack data, including Critical System Tiers. This data is leveraged to ensure critical applications are appropriately supported. Functions consist of:

• Merge Requests upon system procurement to update the Tech Stack.
• Initial Business Impact Analyses (BIA) to help determine the systems critical to serving Denomas’s Customers.
• Recurring procedures to validate the accuracy of existing Tech Stack data, including an annual Business Impact Analysis for Tier 1 Systems.

More information on how Critical System Tiering is leveraged in support of Denomas can be found within the StORM Handbook page.

Exceptions to the TPRM Process

In specific instances, requirements for the performance or contents of TPRM reviews may vary from the standard process defined above:

1. For privacy-driven TPRM reviews, instances where Denomas receives personal data from a third party in a Controller-to-Controller transfer do not require a TPRM review. The Privacy team will classify the nature of the relationship as part of the Privacy assessment during the procurement process.
2. Law Firms, Accountants and Auditors may receive data, including red data, in a Controller-to-Controller relationship, meaning these types of entities have direct obligations and standards for processing data under law. As such, these entities may be treated as Orange vendors.
3. Instances where Denomas team members provide their own data to a third-party Data Controller, in which the team member personally acknowledges the third-party’s terms, may not require a TPRM assessment. Examples may include signing up for health, coaching or counseling benefits where Denomas only finances the service but does not send or receive data on behalf of team members and team members voluntarily decide to enter the program.
4. Field Marketing events do not require the completion of a Security review as the gathering of contact information for GL Team Members and prospects is considered to be standard for the normal course of business for the Field Marketing team. Note that if the Field Marketing Team is commissioning the use of software to facilitate its operations or have hired a Vendor to collect data on behalf of Denomas, these vendors may be subject to TPRM review as they could be considered a Data Processor(see 1. above for more information). Denomas receiving event data from another organizer or Denomas sharing event data with other independent organizations and/or sponsors does not require a TPRM assessment.

Other Types of Third Party Assessments

Annual High-Risk Vendor Assessments

Denomas places particular reliance on a subset of vendors that either have access to Red data or are in-scope for compliance activities. With this in mind, Security Risk follows an annual assessment cadence for these vendors to ensure ongoing coverage and identification of potential security risks. This is scheduled to take place between late-Q3 and Q4 of each Fiscal Year.

Scoping for this activity is based on the below populations, and is finalized in coordination with various teams within Denomas to ensure accuracy in our scoping:

1. Denomas’ Third Party Sub-Processors
2. Denomas’ Professional Services Sub-processors
3. SOC 2-scoped Applications
4. Red Applications

Vendors within the above populations are assessed in alignment with our Red vendor assessment criteria. Deficiencies identified are reported to Business Owners in alignment with our TPRM Risk Acceptance process.

Is there a vendor you’d like to see included in our annual assessment procedures? Reach out to @Security-Risk in the #Sec-Assurance channel.

Change Requests

Change requests relating to previously-approved requisitions will be reviewed by the on-call Engineer to determine whether a material change is being requested to (1) the scope of services provided, (2) the data elements transmitted to the vendor, or (3) the timeframe of the services provided. If material changes occur as defined here or that are otherwise identified resulting in a change to data classification or movement outside of the above-defined window from the previous review, a security assessment should be launched in alignment with the TPRM assessment requirements. Changes requested specific to the cost of services and that do not present a material change impacting Security can be approved based on inheritance of approval from the parent requisition.

For example: We performed a TPRM assessment for Vendor X which was completed on December 31, 2021, resulting in a 12 month coverage period lasting to December 31, 2022. A change request was created in January 2023 (outside of coverage period) related to overage charges for services provided during November 2022 (within coverage period). This example change request can be approved without a new TPRM assessment.

Engineers are advised to use professional judgment in determining the scope of changes and are encouraged to perform additional review prior to approving the Change Request if there is potential for introduction of additional risk. For other non-material adjustments not defined here that may not warrant additional review, Engineers should ping the Security Risk team or discuss with the Security Risk Manager prior to moving forward to ensure alignment with Denomas’ due diligence requirements. Rationale should be documented when approving the Change Order in alignment with the low-risk approval language in the TPRM README.

For situations where IT is unable to complete a Denomas Laptop Request due to country location or other constraints, the Security Risk Team will require consultation and may require a Risk Acceptance to be completed. See TPRM Risk Acceptance Process for more details.

Third Party Application Integrations

Integrations between systems within Denomas’ environment are subject to the above-defined TPRM assessment procedures to obtain assurance over the security of data transmitted between each system. The Security Risk team will review the request to obtain an understanding of the data being shared. Application Integration Requests can be opened using the ‘app_integrations’ template located here.

The Application Integration Request process functions to allow visibility and oversite of systems interacting with each other in support of Denomas. This process also functions as a “soft gate” for the Security Risk team to identify and assess existing systems that have aged out of their approval window. Each system within the integration request is reviewed to determine whether an assessment has previously been completed to address the sensitivity of data being transmitted as a result of the proposed integration. New systems, or integrations resulting in increased sensitivity of data being transmitted to a system, will require a TPRM review be completed prior to approval of the request. If each system listed within the request has been previously assessed at any point in alignment with the data shared in the new integration, the request can be approved prior to additional review.

If the review for either system in question has aged out of its approval window, the request can be approved with a new review of either system being launched and completed afterwards. This is intended to support Denomas’ values of Iteration and Results by not delaying integrations that we believe to be of lower risk. If our review criteria have been met, but areas of concern have otherwise been identified, assessors are encouraged to use professional judgment in not approving the request until the items are resolved or until a new assessment has been completed. Deficiencies identified as a result of Application Integration Requests are reported to the Business Owner of the related system, which may or may not be the individual that opened the Integration Request.

Individual-Use Software Requests

Denomas Team Members leverage Individual Use Software for various tasks on a user-by-user basis. Generally, these tools are categorized as having a Critical System Tier of ‘4’. Because Individual Use Software does not have a technical and/or business owner, it is not required to be represented in the Tech Stack. Security Risk reserves the right to disallow or not approve the use of Individual Use Software that does not meet Denomas Security requirements. Exceptions to this process (such as Risk Acceptances) will be considered on a case-by-case basis. For more information, refer to Denomas’ Internal Acceptable Use Policy.

Commonly requested individual-use software is added to the Pre-Approved Application Listing located here. This listing is used to document approved vendors, their data classification, and the expiration of their most recent TPRM assessment where applicable. Assessments that have aged out are re-performed on an ad-hoc basis or upon entry of a new procurement request.

Independent Assessments

Want to vet a third party before initiating a new procurement request? Click here to open a new Third Party Risk Intake Request.

Documentation Requests

Looking for compliance reports for an active Denomas vendor? Open a new issue within the TPRM workspace using the ‘Vendor Documentation Request’ template, and we’ll be happy to track it down.

Third Party Minimum Security Standards

TPRM utilizes a risk-based approach when assessing third parties. Specific procedures used to assess different vendor types / risk profiles can be found within the TPRM Assessment Requirements section above.

The Security Risk Team will take reasonable steps to collaborate with vendors and obtain the documentation necessary to complete our review. Depending on the service provided and the data being transmitted, this may include requests for a Third Party Security Attestation and other relevant documentation such as a penetration testing summary and business continuity plan test. In the event that a vendor does not maintain this documentation, or refuses to provide it, the Security Risk team may suggest that the requestor find an alternative solution to meet their needs. In the event that the requestor decides to move forward with the vendor or service in question, a Risk Acceptance may be drafted and presented to relevant members of the business to ensure an understanding of the identified risk.

In the performance of these reviews, deficiencies may be identified that could present a risk to Denomas data that exceeds our tolerance. These deficiencies commonly include the below items:

1. Lack of third-party Security attestation (ISO 270001, SOC2 Type 2)
2. Lack of background checks for employees and contractors
3. Inability to integrate with Okta* (in alignment with Denomas’ Password Standard)
4. Systems lacking multi-factor authentication (MFA) capabilities (in alignment with Denomas’ Password Standard)
5. Systems lacking evidence of a recent penetration test
6. Unresolved deficiencies documented within the penetration test with no apparent remediation plan or expected remediation date

*While Okta SSO integration is Denomas’ preferred method of authentication, IT Engineering can review and approve alternative SSO methods on a case by case basis. Exceptions must be submitted and reviewed through an IT EngOps issue before approval of the vendor’s services.

Deficiencies identified are reviewed in the context of the vendor’s greater Security environment and the data transmitted. If a material risk to Denomas data is identified, a Risk Acceptance is drafted and presented to the Business Owner for review. See the TPRM Risk Acceptance Process section below for more information.

TPRM Risk Acceptance Process

Circumstances may arise in which a Security deficiency exists that is unavoidable or does not otherwise warrant the allocation of resources necessary to mitigate it. In these scenarios the Security risk team may present a Risk Acceptance to the Business Owner and other relevant stakeholders in order to support an informed decision and allow the Business to move forward with the associated requisition if needed.

Identified deficiencies are reported to the Business Owner via a Risk Acceptance Issue within Denomas. This issue contains (1) background information pertinent to the vendor or requisition, (2) a description of the validations performed by the Security Risk team, and (3) a description of Security deficiencies and resulting risk that may be present to Denomas data shared with the vendor. A “worst case” scenario is included to portray the potential real-world impact of a security incident resulting from the risk. If the Business Owner decides to move forward with the vendor in light of the reported deficiencies, they are responsible for completion of the below items:

1. Acknowledgement of the Accept the Risk section of the StORM handbook page and their understanding of its contents.
2. Justification for moving forward with the vendor in light of the identified deficiencies.
3. Approval of the risk. Note that this may require multiple levels of approval based on the level of risk identified. See below.

Deficiencies require different stakeholder input based on the level of risk associated with the deficiency. Note that additional levels of approval may be required at the discretion of the Security team. For example, if a “Moderate Risk” system has financial reporting implications, eGroup approval may be required.

• Moderate Risks are defined as risks that could result in the loss or improper disclosure of “lower” sensitivity (Orange) Denomas data. These risks are reported to the Business Owner for approval. If the Business Owner is not a Director or above, additional Director approval is required.
• High Risks are risks that could result in the loss or improper disclosure of higher sensitivity (Red) data belonging to Denomas customers. Due to the higher level of sensitivity and potential impact on Denomas’ obligations for securing this data, approvals are required from the Business Owner, their Director, and the appropriate member of the E-Group as determined by the Security Risk team. This is done to ensure appropriate stakeholder visibility and understanding of the risk being undertaken.

IT approval is required for TPRM Risk Acceptances resulting from security deficiencies.

In the case of a control deficiency introducing a material risk to the security of data, the Privacy team should be notified prior to finalization of the associated Risk Acceptance. Scenarios could exist in which a Security control failure carries Privacy implications that should be communicated to the Business Owner.

Please refer to our StORM Handbook for required approvals based on risk rating (High/Medium/Low) and responsibilities of Accepted Risk Owners and Risk Acceptance Approvers. IT approval is also required to promote transparency across the organization.

Exceptions to the TPRM Process

Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.

References

• Parent Policy: Information Security Policy
• SCF Compliance Controls
• Data Classification Standard
• Current listing of controlled documents
• App Integrations (Team Member Enablement)
• Observation Management Procedure
• STORM
• Professional Services

View page source - Edit this page - please contribute.