{
 "questionnaire": {
  "id": "pca-vendor-cyber-questionnaire",
  "version": "1.0",
  "published": "2026-11-11",
  "publisher": "Port Cyber Alliance",
  "url": "https://portcyberalliance.org/open-source-packages/vendor-questionnaire-open-source/",
  "derived_from": {
   "id": "pca-vendor-cyber-onboarding",
   "version": "1.0",
   "url": "https://portcyberalliance.org/resources/vendor-cyber-onboarding/"
  },
  "licence": "CC-BY-4.0",
  "licence_url": "https://creativecommons.org/licenses/by/4.0/",
  "how_to_use": "A terminal or a port sends this questionnaire to a software vendor before connecting its software. The vendor answers every question with the scale below, writes what it really does, and attaches the evidence. An honest « planned, with a date and an owner » is better than a vague yes. The terminal reads the answers family by family and asks for the missing evidence."
 },
 "answer_scale": [
  {
   "code": "yes-evidence",
   "label": "Yes, with evidence attached"
  },
  {
   "code": "yes",
   "label": "Yes, no evidence yet"
  },
  {
   "code": "planned",
   "label": "Not yet, planned with a date and an owner"
  },
  {
   "code": "no",
   "label": "No"
  },
  {
   "code": "n-a",
   "label": "Not applicable, with the reason"
  }
 ],
 "requester_fields": [
  {
   "id": "organisation",
   "label": "Terminal or port"
  },
  {
   "id": "contact",
   "label": "Contact person"
  },
  {
   "id": "email",
   "label": "Contact e-mail",
   "type": "email"
  },
  {
   "id": "sent",
   "label": "Date sent",
   "type": "date"
  },
  {
   "id": "due",
   "label": "Answers expected by",
   "type": "date"
  },
  {
   "id": "scope",
   "label": "Software and connection in scope",
   "type": "textarea"
  }
 ],
 "respondent_fields": [
  {
   "id": "company",
   "label": "Vendor company"
  },
  {
   "id": "product",
   "label": "Product and version"
  },
  {
   "id": "contact",
   "label": "Contact person"
  },
  {
   "id": "email",
   "label": "Contact e-mail",
   "type": "email"
  },
  {
   "id": "date",
   "label": "Date answered",
   "type": "date"
  }
 ],
 "families": [
  {
   "id": "access",
   "name": "Access",
   "why": "Remote access by suppliers is one of the ways into a terminal's network. The terminal wants to know who at your company can reach its systems, how, and how that access ends.",
   "questions": [
    {
     "id": "ACC-01",
     "text": "Who in your company can reach our systems or our data, by role, and how many people is that?"
    },
    {
     "id": "ACC-02",
     "text": "How do they connect (our VPN, a jump host, your own remote tool), and can we approve or cut each session?"
    },
    {
     "id": "ACC-03",
     "text": "Is multi-factor authentication required for every person, including administrators and support staff?"
    },
    {
     "id": "ACC-04",
     "text": "Are accounts named and personal, with no shared or default passwords?"
    },
    {
     "id": "ACC-05",
     "text": "How fast is access removed when someone leaves your team, and how often do you review the list with us?"
    }
   ],
   "prepare": [
    "A list of roles with access, and what each role can do",
    "A diagram of the remote-access path, through the terminal's own entry point",
    "The multi-factor method used, and single sign-on if you support it",
    "Your joiner and leaver procedure, with the time to remove access"
   ],
   "model_answer": "Our support engineers reach your environment only through the path you choose, your VPN or your jump host, and each session can be approved and closed by your team. Every person has a named account with multi-factor authentication; there are no shared accounts and no default passwords. Access is granted for a ticket and removed within [time] of a person leaving the team. We review the list of people with access with you every [period].",
   "sources": [
    "cisa-sbd-ot",
    "cisa-sbd-guide",
    "imo-rev4"
   ]
  },
  {
   "id": "data",
   "name": "Data",
   "why": "The terminal stays responsible for its data, and often for personal data of drivers, crews and staff. It needs to know what you hold, where, and who can read it.",
   "questions": [
    {
     "id": "DAT-01",
     "text": "What data of ours do you store or process, and which of it is personal data?"
    },
    {
     "id": "DAT-02",
     "text": "In which countries is it hosted, and by which hosting provider?"
    },
    {
     "id": "DAT-03",
     "text": "Is it encrypted in transit and at rest, and who holds the keys?"
    },
    {
     "id": "DAT-04",
     "text": "How is our data kept apart from your other customers' data?"
    },
    {
     "id": "DAT-05",
     "text": "How long do you keep each kind of data, and can we change that?"
    }
   ],
   "prepare": [
    "A data-flow diagram from the terminal's systems to yours and back",
    "The hosting locations and providers",
    "The encryption used in transit and at rest, and the key management",
    "A retention table by kind of data"
   ],
   "model_answer": "We process [list of data], of which [list] is personal data. It is hosted in [country] by [hosting provider]. Data is encrypted in transit and at rest; keys are managed by [who]. Each customer's data is kept in a separate [database / tenant] and our staff read it only for a support ticket you opened. We keep [data] for [period], and you can ask for a shorter period.",
   "sources": [
    "enisa-supply-chain",
    "nist-800-161",
    "imo-rev4"
   ]
  },
  {
   "id": "logs",
   "name": "Logs",
   "why": "Without logs, a terminal cannot see what happened in your software, nor send it to its own monitoring. Logging that costs extra or cannot leave your platform is a common blocker.",
   "questions": [
    {
     "id": "LOG-01",
     "text": "What do you log (logins, administrator actions, changes of settings, API calls, data exports)?"
    },
    {
     "id": "LOG-02",
     "text": "How long do you keep the logs, and are they protected against change?"
    },
    {
     "id": "LOG-03",
     "text": "Can we receive the logs in our own monitoring tool (SIEM), in a standard format, at no extra cost?"
    },
    {
     "id": "LOG-04",
     "text": "Are the clocks of your systems synchronised, so that times match ours?"
    }
   ],
   "prepare": [
    "A catalogue of the events you log, with one example of each",
    "The retention period and how logs are protected",
    "The export options (syslog, JSON over HTTPS, a file drop) and their format"
   ],
   "model_answer": "We log logins, administrator actions, changes of settings, API calls and data exports, with the user, the time and the source address. Logs are kept [period] and cannot be changed by the people they record. We send them to your SIEM by [syslog / HTTPS] in [format], at no extra cost. All our servers are time-synchronised.",
   "sources": [
    "cisa-sbd-guide",
    "cisa-sbd-ot",
    "imo-rev4"
   ]
  },
  {
   "id": "backups",
   "name": "Backups",
   "why": "A terminal works around the clock. If your service stops or its data is encrypted by ransomware, the terminal wants to know how fast it comes back and with how much data lost.",
   "questions": [
    {
     "id": "BAK-01",
     "text": "How often is our data backed up, and where are the backups kept?"
    },
    {
     "id": "BAK-02",
     "text": "Are backups separated from the production systems, so that one attack cannot reach both?"
    },
    {
     "id": "BAK-03",
     "text": "When did you last restore from a backup as a test, and what was the result?"
    },
    {
     "id": "BAK-04",
     "text": "How long does it take to restore the service, and how much data can be lost at most?"
    }
   ],
   "prepare": [
    "The backup schedule and the backup locations",
    "How backups are isolated (offline, immutable, another account)",
    "The date and the report of the last restore test",
    "The restore time and the maximum data loss you commit to"
   ],
   "model_answer": "Your data is backed up every [frequency] to [location], separate from production and protected against deletion for [period]. We tested a full restore on [date]; it took [time]. We commit to restore the service within [time] with at most [time] of data lost, and we will show you the next restore test.",
   "sources": [
    "imo-rev4",
    "enisa-supply-chain"
   ]
  },
  {
   "id": "incidents",
   "name": "Incidents",
   "why": "In the European Union, an operator in scope of NIS2 sends an early warning within 24 hours of becoming aware of a significant incident, and a notification within 72 hours. It can only meet that if its suppliers tell it fast.",
   "questions": [
    {
     "id": "INC-01",
     "text": "How and how fast will you tell us about an incident that affects our data or our service?"
    },
    {
     "id": "INC-02",
     "text": "Who is our contact during an incident, and can we reach them at any hour?"
    },
    {
     "id": "INC-03",
     "text": "What will your first notice contain, and how will you keep us updated?"
    },
    {
     "id": "INC-04",
     "text": "Will you help us with our own notifications to the authorities, and share what you learned afterwards?"
    }
   ],
   "prepare": [
    "Your incident response plan, or its summary",
    "A 24/7 contact and the escalation path",
    "A template of the first notice",
    "An example of a post-incident report, anonymised"
   ],
   "model_answer": "We notify your named contact by [phone and e-mail] within [time] of confirming an incident that affects your data or your service. Our first notice says what happened, what is affected, what we have done and what we ask you to do; updates follow every [period] until it is closed. Our incident line answers at any hour. We give you the facts you need for your own notifications, and a written report within [period].",
   "sources": [
    "nis2",
    "imo-rev4",
    "nist-800-161"
   ]
  },
  {
   "id": "subcontractors",
   "name": "Subcontractors",
   "why": "Your suppliers become the terminal's suppliers. The risk does not stop at your company, and the terminal needs to know who else touches its data or its systems.",
   "questions": [
    {
     "id": "SUB-01",
     "text": "Which subcontractors (hosting, support, development, monitoring) touch our data or our systems?"
    },
    {
     "id": "SUB-02",
     "text": "Where are they, and what do they have access to?"
    },
    {
     "id": "SUB-03",
     "text": "Do your security requirements apply to them in their contracts?"
    },
    {
     "id": "SUB-04",
     "text": "Will you tell us before you add or change a subcontractor?"
    }
   ],
   "prepare": [
    "The list of subcontractors, their role, their country and their access",
    "The security clauses you pass on to them",
    "Your rule for telling customers about a change"
   ],
   "model_answer": "[Number] subcontractors touch your data or systems: [hosting provider] for hosting in [country], [provider] for [role]. Each is bound by the same security requirements we accept with you, in their contract. We will tell you [period] before adding or changing one, and you may object.",
   "sources": [
    "nist-800-161",
    "enisa-supply-chain",
    "nis2"
   ]
  },
  {
   "id": "penetration-tests",
   "name": "Penetration tests",
   "why": "A terminal wants proof that someone outside your team has tried to break your software, and that what they found was fixed. It also wants to know how you handle vulnerabilities found later.",
   "questions": [
    {
     "id": "PEN-01",
     "text": "When was your software last tested by an independent penetration tester, and what was in scope?"
    },
    {
     "id": "PEN-02",
     "text": "Can we see a summary of the findings and how each one was fixed?"
    },
    {
     "id": "PEN-03",
     "text": "May we, or a tester we choose, test the service we use?"
    },
    {
     "id": "PEN-04",
     "text": "Do you publish a vulnerability disclosure policy, and how fast do you fix critical vulnerabilities?"
    }
   ],
   "prepare": [
    "The date, the scope and the tester of the last test",
    "A summary of findings and fixes that you can share",
    "Your rules for a test by the customer",
    "Your vulnerability disclosure policy and your patching times"
   ],
   "model_answer": "An independent firm tested [scope] on [date]. We share the summary of findings and the fix for each one under non-disclosure. You may test the service you use, with [notice] notice and the rules of engagement we agree. Our vulnerability disclosure policy is published at [URL]; we fix critical vulnerabilities within [time].",
   "sources": [
    "cisa-sbd-guide",
    "cisa-sbd-ot",
    "nist-800-161"
   ]
  },
  {
   "id": "end-of-contract",
   "name": "End of contract",
   "why": "The day the contract ends, the terminal must get its data back, and be sure your company no longer holds it or can reach its systems.",
   "questions": [
    {
     "id": "END-01",
     "text": "In which format do we get our data back, and how long do you take?"
    },
    {
     "id": "END-02",
     "text": "How do you delete our data, including backups, and do you confirm it in writing?"
    },
    {
     "id": "END-03",
     "text": "How are your accesses, accounts and keys to our systems removed?"
    },
    {
     "id": "END-04",
     "text": "What help do you give to move to another system?"
    }
   ],
   "prepare": [
    "The export formats and the time to deliver them",
    "Your deletion procedure, backups included, and a deletion certificate template",
    "The checklist of accesses and keys removed at the end",
    "The transition support you offer"
   ],
   "model_answer": "At the end of the contract, we deliver your data in [format] within [time]. We then delete it from production and from backups within [period], and confirm it in writing. All our accounts, accesses and keys to your systems are removed on the last day, and we send you the checklist. We support the move to another system for [period].",
   "sources": [
    "enisa-supply-chain",
    "nist-800-161"
   ]
  }
 ],
 "sources": [
  {
   "id": "imo-rev4",
   "title": "IMO, Guidelines on maritime cyber risk management, MSC-FAL.1/Circ.3/Rev.4",
   "date": "2026-05-28",
   "url": "https://wwwcdn.imo.org/localresources/en/OurWork/Security/Documents/MSC-FAL.1-Circ.3-Rev.4.pdf"
  },
  {
   "id": "nist-800-161",
   "title": "NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations",
   "date": "2022-05 (updated 2024-11-01)",
   "url": "https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final"
  },
  {
   "id": "enisa-supply-chain",
   "title": "ENISA, Good Practices for Supply Chain Cybersecurity",
   "date": "2023-06-13",
   "url": "https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity"
  },
  {
   "id": "cisa-sbd-guide",
   "title": "CISA, Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem",
   "date": "2024-08",
   "url": "https://www.cisa.gov/resources-tools/resources/secure-demand-guide"
  },
  {
   "id": "cisa-sbd-ot",
   "title": "CISA and partner agencies, Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products",
   "date": "2025-01-13",
   "url": "https://www.cisa.gov/resources-tools/resources/secure-demand-priority-considerations-operational-technology-owners-and-operators-when-selecting"
  },
  {
   "id": "nis2",
   "title": "Directive (EU) 2022/2555 (NIS2), Articles 21 and 23",
   "date": "2022-12-14",
   "url": "https://eur-lex.europa.eu/eli/dir/2022/2555/oj"
  }
 ]
}