September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
As far as i know, first step is to define security risks to any kind of information you need to supply to Thrid Party. It´s must be your main concern.
A risk assessment requires you to review the potential threats your third-party service providers bring with them. Unfortunately, as threats evolve, risks change. Since malicious actors continuously update how they infiltrate information, you need to start with the primary risks and expand to a continuous monitoring model.
Only after that you can do next steps:
Step 1: Identify the Information Your Vendor Accesses
Vendor risk directly relates to the information that your vendor accesses. Vendors come in a variety of types. The same way that you need to identify internal information assets, you need to identify vendor information assets. To appropriately determine the risk your vendor poses to your organization, you need to ask yourself the following questions regarding your vendors:
What is the role my vendor plays in my business?
What company information does the vendor need to meet these needs?
What employee information does the vendor need?
What customer information does the vendor need?
Does the vendor need access to my systems and networks?
What systems and networks do my vendor need access to?
How long will my vendor need access to my systems and networks?
Service providers can be people or software systems. To appropriately evaluate your risk, you need to understand how they fit into your business objectives as well as how much information they need to enable those objectives.
Step 2: Set a Risk Tolerance for Vendors
Once you determine the information that your vendors access, you need to align your information risk tolerance to match the access your vendors need. You need to decide what risks you want to accept, transfer, mitigate, or refuse. Looking at your vendor needs, you need to ask yourself the following questions:
Does this vendor play a critical role in my business operations?
How much company information does the vendor need?
How much customer information does the vendor need?
How much employee information does the vendor need?
How many critical networks does the vendor need to access?
How many critical systems does the vendor need to access?
Criticality to your business operations acts as the first step to understanding the impact the vendor can have on your organization.
Your IT department may use a cloud service provider to house all your electronic data. Meanwhile, your marketing department may be using a vendor to manage email distributions. Each of these vendors has access to valuable information, but the information differs in criticality to your business operations. Your cloud service provider houses information such as customer or employee names, dates of birth, or financial information. If this data is compromised, you face legal issues. If you lose a batch of email addresses for outreach, your liability is less, especially if the information does not personally identify any of the potential individuals linked to the emails.
Therefore, your cloud service provider is a more critical vendor to business continuity and houses more important information making them a high risk.
Step 3: Create Procedures to Guide Your Vendor Relationship
If good fences make good neighbors, then good contracts make good business partnerships. Creating the right documentation to formalize your relationship outlines a set of shared best practices that you expect your vendor to follow. A service level agreement (SLA) is a contract that outlines the role your vendor will play in your company.
Primarily focused on the services provided and the completion expectations for a project, SLAs increasingly also define security requirements for vendors. These contracts, especially for long-term relationships, create boundaries that define legal responsibility for data protection. When creating your SLA, you want to incorporate, at a minimum, the following:
Access authorization protocols
Information access controls
Password management requirements
Network and system security protections
Network and system update requirements
Employee Security Awareness Training requirements
Encryption and decryption requirements
End-point security requirements
Liability for security incidents
Vendors need to have a clear set of security expectations. Additionally, you need to know that they meet your security requirements. For example, if you require multi-factor authentication for application use but your vendor does not, they can put you at risk. If you’re constantly updating your systems with provider patches, but they do not do this regularly, they put your information at risk. You need to have some assurance that they know your requirements and their responsibility in case they do not meet them.
Step 4: Ongoing Vendor Monitoring
Your vendors’ security posture poses the same risk to your data that yours poses, except you have less control over their activities. Lacking control over vendor security protocols and controls feels unnerving. Knowing that their missteps become your missteps can escalate even the calmest CISO’s blood pressure. Continuous monitoring strategies include:
Reviewing SOC reports
Making site visits
Engaging in vendor audits either annually or more frequently
Requesting penetration testing documentation
Reviewing copies of internal audit reviews
Reviewing IT diagrams and architecture
Reviewing security documentation
Vendor oversight and monitoring require both trusting your vendors to meet contractual obligations as well as verifying that trust with documentation. Meeting your compliance requirements, both regulatory and industry-imposed, requires you to create an effective monitoring process that protects your downstream partners and customers.
Thank you Eduardo! This is very helpful information!
Please login or join to reply