Use one response per organization and scope
This questionnaire measures stated security practices within a named product or business unit. Version 2.0 has 13 questions, a defined reporting period, and evidence rules. The file contains no answers or market findings. A security lead can use it with payment, operations, and identity teams before an annual review.
Choose the unit before invitations: one legal entity and its named payment product or business unit. Record what systems it covers. A group with two separate units can submit two responses only if the study chose units as its sample. Do not count both units and their parent as three organizations. Publish the choice with the results.
Set the reporting period first
Use a completed calendar year with explicit start and end dates. For example, a 2025 study covers 1 January through 31 December 2025. Fieldwork can happen later, but answers must describe that period. Record fieldwork dates separately. Questions marked period_end describe controls on 31 December; questions marked reporting_period ask whether a review or test occurred during the year. A control added after that date cannot earn a yes for the prior year.
Write the in-scope product list and key control register before answering. In scope means the systems and controls named in that list. Yes means the full question is true for all applicable items. No means at least one applicable item did not meet it. Unknown means the respondent cannot decide. Not applicable is allowed only under the rule in that row, with a reason. A missing test means no for a question asking whether a test occurred; unknown means records cannot establish whether it occurred.
Assign one respondent and resolve conflicts
The organization names one respondent who gathers input from the control owners and signs off the final file. Record respondent role, unit ID, question version, period, and submission date in a private response file. Contributors do not submit separate counted answers. If two owners disagree, the designated respondent checks the scoped records. An unresolved factual conflict becomes unknown with a private note. Keep answer changes and their reasons. Lock the final answer at the study closing date.
Ask one question at a time
Client retry prevention and provider webhook redelivery are separate measures: Q02 covers the client request; Q13 covers the webhook event. Payment vendor reviews remain Q05; identity vendor reviews use Q14. Q04 asks for a dated payment timeline test. Q10 is retired because it repeated Q04. The version notes record these changes so researchers do not join old and new answers as one measure.
Q07 has one approval-binding rule with two required fields: amount and destination. A yes requires both field-change tests to invalidate approval. Q12 asks only about expiry dates; owner assignment needs a separate question in a later version. Every CSV row gives a definition, time basis, allowed answers, an exact not-applicable rule, and the record needed to support the answer.
Keep self-report and checked evidence visible
Store answer and evidence status as separate fields. Use self_report_only when no reviewer inspected a record. Use evidence_supports when a reviewer saw a dated, in-scope record that supports every part of the answer. Use evidence_conflicts when that record contradicts the answer. Use evidence_insufficient when the supplied record has no date, covers only part of the scope, or cannot establish the claimed action. Record reviewer ID, check date, covered scope, and a short reason. These are survey evidence labels; they do not certify a system.
For synthetic Q02, a respondent answers yes for three payment routes. The attached retry test covers only route A. Mark evidence_insufficient, retain the reported yes, and record that B and C remain unchecked. Request those records or an answer correction before closing. Do not silently turn a self-report into a verified result. For Q05, no new payment vendor during the year supports not applicable, with the reason recorded.
Pilot before collecting annual answers
Run a small pilot with a payment engineer, security lead, and operations lead from several units. Ask each to explain what a question means, choose an answer, and name supporting evidence. Record unclear words, answer conflicts, time taken, and items left blank. Check that each not-applicable rule is usable. Revise the instrument and raise its version before the main study. Keep pilot responses out of annual results unless the final wording and period match and participants consent to inclusion.
Report a denominator for each question
Suppose 20 eligible units are invited and 8 answer Q02: 4 yes, 2 no, 1 unknown, and 1 not applicable. These are synthetic counts. Report all four counts and 12 missing responses. The applicable known-answer proportion is 4 of 6; the share of all respondents answering yes is 4 of 8. Name the denominator each time. Neither result describes every Nigerian fintech. A voluntary sample gives no basis for a market-wide estimate without a justified sampling method.
Release recruitment rules, eligibility list counts, invitation counts, field dates, organization mix, exact wording, missing answers, version changes, and evidence-check counts with future findings. AAPOR’s transparency guidance supports making study methods public with results. The OWASP logging guide informs the timeline evidence question. Obtain consent for quotes and permitted sharing; remove identifying records before release.
Download the version 2.0 questionnaire and period, evidence, and version notes. The existing download URL now serves version 2.0; the version column identifies the instrument. Run the pilot, then use the security culture guide to assign owners or request a security review.