Third-Party Security Review Preparation

Prepare a vendor assessment that reviewers can act on the first time For project sponsors bringing a new third-party service to IT and Security. The example below follows Northstar Works, a fictional organization piloting an outside scheduling service. Gather three things before you submit: what data the service will hold, who and what will have access, and what evidence the vendor can supply. Reviewers then spend their time assessing risk instead of chasing basics. Three things to prepare These are preparation topics, not separate approvals. Work through them in any order; together they make up your request. Data involved Describe what the service will store or process, and for whom. List each data type, such as work email or shift preferences Estimate how many people's data is included Note where data comes from and where it goes Write down what you do not yet know about retention Access model Say who and what will be able to reach the data. Name the user groups at your organization List integrations, such as sign-in or HR system connections Ask whether vendor staff can view customer data, and why State the pilot's start and end dates Vendor evidence Collect what the vendor already publishes or will share. Request the current security overview for this specific service Ask how the vendor notifies customers of an incident Note any conditions on sharing documents Record gaps as questions for the vendor, not assumptions Worked example: a scheduling pilot at Northstar Works A fictional sponsor's notes, written the way a reviewer needs to read them Business purpose. Two operations teams (about 150 people) will try an outside scheduling service for 90 days to replace shared spreadsheets. Data involved Employee name and work email, entered by team leads. Shift preferences and availability, entered by each employee. Not planned: home addresses, payroll data or health information. The sponsor will confirm this with the vendor in writing. Access model Employees sign in to view their own shifts; two team leads edit schedules. A vendor support role may access the account to troubleshoot. Question for the vendor: is that access logged, and can customers approve it each time? No integration with other systems during the pilot. Open questions, not assumptions What happens to schedule data when the pilot ends? Where is the data stored and processed? Notes like these let a reviewer see what is known, what is unknown and who owes the answer. Vendor evidence to ask for Ask the vendor for each item and record their answer in their own words. Reviewers decide what the answers mean. Ask the vendor for Why reviewers ask Your action Security overview for this service Shows how the vendor describes its own controls Request the current version and note its date Incident contact process Shows how and when customers are told about an incident Record who contacts whom, by what channel, and the stated timeframe Data location and processing Lets reviewers compare handling against the data types you listed Ask which regions are used and whether support staff view data from elsewhere Subprocessors Identifies other companies that may touch your data Request the list and how customers are told of changes Retention and deletion Clarifies what remains after the pilot ends Ask what is kept, for how long, and how deletion is requested Independent assessment reports May give reviewers outside assurance, if the vendor has any Ask what can be shared and under what conditions From preparation to review handoff Specialists assess the material and decide next steps. Your part is to make their starting point complete. State the business purpose and scope One short paragraph: what the service does, which teams use it, and the pilot or contract dates. Describe data and access Use the example above as a pattern. List data types, who has access, integrations, and open questions. Gather the vendor's evidence Send the vendor the questions in the table. Keep their replies and note anything they decline to share. Submit through your organization's approved request route Attach the material there. Keep sensitive details out of chat, email threads and page comments. Answer reviewer follow-up Security, privacy and other designated reviewers may ask for clarification. Reply in the same request so the history stays in one place. Who does what Keep these roles distinct so each question reaches the right person. Describe the business purpose Writes and owns it Reads and may ask questions Data and access details Provides what is known and flags gaps Checks them against approved requirements Vendor evidence Requests and attaches it Evaluates what it does and does not show Risk decision and conditions Responds to follow-up Security, privacy and other reviewers decide Sourcing and contract terms Coordinates with procurement Handled separately by procurement, not this review Who to ask for help Ask about what a request needs, how reviewers will handle it and where it stands Security review owner IT and Security Ask about project dates, budget approvals and the separate sourcing and contract process Your project or procurement contact Project office or Procurement