Security and access

Executive support security questionnaire for providers

Ask practical questions about identity, devices, data handling, incidents, subcontractors, continuity, and offboarding before granting executive access.

Hiring guide desk with scorecards, interview notes, and executive support planning materials
In this guide
  1. Define the executive support outcome
  2. Match role scope to leadership cadence
  3. Use a structured selection process

Start with the real decision

Which security questions should a leadership team ask an executive assistant or support provider? The answer should follow the leadership team's real workflows, risks, and capacity rather than a generic rule. The questionnaire should follow the actual scope. Calendar scheduling, inbox delegation, board materials, travel profiles, and payment coordination expose different information and actions. Start with a data and access map, then ask how the provider protects each workflow. The aim is reasonable risk management and clear ownership, not collecting impressive policy names. A small provider can give precise, trustworthy answers; a large provider can still leave dangerous gaps between its corporate policy and the assistant's daily tools.

Avoid the common shortcut

Do not treat a questionnaire response as proof by itself, and do not ask for sensitive security details that your team cannot protect. Avoid yes-or-no questions such as are you secure. Ask for the control, owner, evidence, and exception process. Never send passwords by email as part of onboarding. If the scope includes regulated, privileged, financial, health, or other specialized information, involve the qualified security, privacy, legal, or compliance owners for your organization and jurisdiction.

Map the work

Ask about identity and access. Does each assistant use an individual account? Is multifactor authentication required? Who approves access, reviews it, and removes it? Can a provider administrator enter client systems? How is emergency access controlled? Request a list of the systems in scope and the minimum role needed. Least privilege matters most when it is expressed as a real permission, not a general principle.

Make ownership explicit

Ask about devices and work locations. Determine whether the assistant uses a provider-managed or personal device, how updates, screen locks, encryption, malware protection, and device loss are handled, and whether others can access the workspace. Clarify rules for public Wi-Fi, printing, local downloads, removable media, and personal email. Match the requirements to the sensitivity of the work rather than assuming remote work is either inherently safe or unsafe.

Test the operating model

Ask about data flow and retention. Where may executive information be stored, copied, backed up, or processed? Which collaboration and artificial intelligence tools are approved? Are subcontractors or subprocessors involved? How long are exports, recordings, and local files retained, and how is deletion confirmed? The provider should be able to distinguish client-owned systems from its own operational records and explain what remains after termination.

Protect access and judgment

Ask about detection and incidents. What must the assistant report, to whom, and how quickly if a message is misdirected, a device is lost, credentials may be exposed, or an unusual payment request arrives? How does the provider preserve facts and coordinate with the client's response owner? CISA publishes incident response resources that emphasize preparation. Even a lightweight plan should name contacts, containment actions within authority, and a path for client decisions.

Choose a reviewable first step

Ask about people, continuity, and offboarding. How are assistants trained on client rules? Who may provide backup, and does the client approve them? What happens when a person leaves the provider? Require prompt access removal, return or deletion of information, and transfer of current work. Revisit the questionnaire when scope, systems, locations, or provider personnel change; a one-time review cannot govern an evolving relationship.

Example for a leadership team

A provider will support one executive's calendar and inbox but not payments or the board drive. The client issues individual accounts, requires phishing-resistant multifactor authentication where available, prevents local inbox export, and approves one named backup only for calendar work. The provider must report suspected account compromise immediately through a defined phone contact. When the primary assistant leaves, access is removed before the replacement begins and the client approves the new person. This control set is narrower and more useful than a generic claim that the provider follows best practices.

Measure whether the choice works

Maintain a simple register of systems, users, permission levels, approvers, review dates, incidents, exceptions, and removal evidence. Sample it after onboarding, a coverage event, and termination. Track overdue access reviews and unresolved exceptions, not vanity counts of policies. A questionnaire creates value only when answers become operating controls with owners.

Review the evidence before approval

Before approving this security and access decision, hold a short evidence review with the executive, the person who will manage the work, and any owner responsible for security, people, tax, legal, or specialist questions raised by the scope. Read the actual proposal, agreement, workflow, or candidate evidence rather than relying on a sales summary. Write what is confirmed, what remains an assumption, which conditions must be satisfied before access begins, and who can accept each condition. Use CISA small and medium-sized business security resources as a primary reference for the relevant external principle, then ask a qualified owner to interpret requirements that depend on your location or facts. The review should produce a go, revise, or stop decision with reasons.

Write the launch brief

Turn the decision into a one-page launch brief. Include the supported leaders, first workflow, intended outcome, input owner, service window, access needed, authority boundary, escalation contact, success evidence, and review date. Link the operating references, including remote executive support security checklist and executive support access review, so the person doing the work can find the surrounding rules. Walk through one normal case, one ambiguous case, and one failure case before expanding the scope. If the team cannot agree on the safe action in those examples, the design is not ready for a new assistant or provider to interpret under pressure.

Turn the guide into an action

Use this guide as a working decision record. Write the assumptions, owner, evidence, next review date, and safe response when an answer is missing. Keep executive judgment with the accountable leader and specialist decisions with qualified owners. HireExecutiveTeam helps leadership teams define and staff practical executive support; a useful next step is to compare the framework here with your current calendar, inbox, meeting, board, travel, and follow-through workload before discussing a role or service.

Related resources

Read also: remote executive support security checklist and executive support access review. Source: CISA small and medium-sized business security resources.

FAQ

What should a leadership team decide first?

Define the outcome, recurring workflows, capacity assumptions, authority boundaries, and the person accountable for exceptions before choosing a provider or role design.

How should the team handle missing information?

Record the gap and its owner, use the safest approved default, and avoid treating an assumption as permission or confirmed fact.

When should the decision be reviewed?

Set a review after the first operating cycle and whenever the scope, supported leaders, systems, access, or risk profile changes materially.

Discuss executive support