An Enterprise Customer Sent a Security Questionnaire: The Armenian Supplier’s Checklist

Armenia is absent from the European Commission’s list of countries with an adequacy decision, and that single fact drives most of what an enterprise security questionnaire asks your company to produce. Your customer cannot move personal data to a supplier in a non-adequate country on trust. It needs a transfer mechanism under Chapter V of the GDPR, in practice the Commission’s standard contractual clauses adopted under Article 46(2)(c), and it needs a file showing that signing those clauses with you is defensible.

The questionnaire is that file. Every item in it maps to an obligation the customer carries, so an answer that reads as evasive stalls the deal inside procurement, before legal ever sees it.

Why enterprise customers send these questionnaires

Article 28 of the GDPR permits a controller to engage only processors that provide sufficient guarantees of appropriate technical and organisational measures. The controller must be able to demonstrate that it assessed those guarantees, and the completed questionnaire, with the evidence attached to it, is that demonstration. Auditors ask to see it, and so, occasionally, does a supervisory authority.

A supplier outside the EEA adds a second file. The customer must document the transfer, identify its Chapter V mechanism, and assess whether the law of the destination country undermines the protection those clauses promise. Your answers are the raw material for that assessment, which is why questions about government access requests and about who can reach the data sit alongside the routine security items.

Remote access counts. Under the European Data Protection Board’s three part test, and as set out in EDPB Opinion 22/2024, making personal data available to an entity in a third country is a transfer even when nothing is copied and the data stays on the customer’s servers. An Armenian engineer holding a support login to an EU customer’s production system triggers the same analysis as a database export.

What is different about an Armenian supplier

The Commission’s adequacy list covers Andorra, Argentina, Brazil, Canada for commercial organisations, the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, South Korea, Switzerland, the United Kingdom, Uruguay, and participants in the EU to US Data Privacy Framework. Armenia does not appear on it. For background on how the two regimes diverge more generally, see our guide to GDPR and Armenian data protection law.

Standard contractual clauses are the practical route. Binding corporate rules under Article 47 are designed for intra-group transfers and are unavailable to an independent supplier. Article 46(2)(d) covers clauses that a supervisory authority adopts and the Commission approves, a separate instrument from the Commission’s own clauses under Article 46(2)(c). Procurement teams sometimes cite the two together; the paper you will be sent is the Commission’s.

The terminology inverts

Armenia’s Law on Personal Data Protection of 18 May 2015, as amended through 4 December 2025, calls the party that determines the purpose of processing the “processor” and the party that processes on instruction the “authorised person”. The GDPR uses those words the other way round, which produces confused questionnaire answers when a supplier maps the Armenian terms straight across. Article 14 requires a written instruction between the two, and the instructing party retains statutory responsibility for what the other does with the data. One well drafted data processing agreement can carry both the customer’s Article 28 requirement and the Armenian written instruction requirement, provided it is drafted to do so.

Onward transfers out of Armenia

Article 27 of the same law governs personal data leaving Armenia, which is the moment you route customer data to a subprocessor in a third country. The inbound direction, your EU customer sending data to you, is governed by the GDPR on the customer’s side. Suppliers running hosting, error monitoring or support tooling abroad hit Article 27 routinely without noticing.

Transfers to a state on Armenia’s official adequate protection list, or made under an international treaty, proceed without separate authorisation. Armenia maintains such a list, updated by a decision of 18 June 2026 and covering roughly 53 countries and entries, among them the EU and EEA states, Argentina, Canada, Israel, Japan, New Zealand, Singapore, South Korea, Uruguay and Russia, with an entry for United States organisations whose limits have not been spelled out in published guidance. For a destination outside the list, the transfer requires prior permission from the authorised body together with contractual safeguards that body has approved. The statutory review period is 30 days, and the list is republished annually.

The document checklist

Six documents answer most of what arrives. Assemble them once and the next questionnaire becomes an editing job.

1. Data processing agreement. The customer sends its own paper. Read it against the Armenian written instruction requirement before signing, and check that its retention and deletion terms match what your systems actually do.
2. Subprocessor register. One row per subprocessor: legal entity and country, purpose, categories of personal data reached, level of access, where processing and access physically occur, the transfer basis for that subprocessor, and confirmation that the customer authorised it. Append your vetting and offboarding process.
3. Transfer paperwork. The executed standard contractual clauses with the correct module for the relationship, plus your written input into the customer’s transfer impact assessment, covering the access requests you could receive and your ability to challenge them.
4. Security policy summary. Two to four pages on access control, encryption in transit and at rest, logging, change management and secure development. Customers rarely accept a flat refusal to share anything, and they rarely need your full internal policy set.
5. Incident response summary. Who is notified internally, the trigger for telling the customer, the channel used, and the contractual notification window you are prepared to commit to.
6. Certifications and test evidence. An ISO 27001 certificate with its statement of applicability, a SOC 2 Type II report if you hold one, and a summary of your most recent penetration test with remediation status. No GDPR certificate exists, and offering one marks the response as inexperienced.

Common questionnaire sections and how to answer them

Entity and ownership details

Questionnaires open with the registered name, registration number, legal address and ownership chain. Take these from your company registration record so the answers match the state register character for character. A mismatch here is what sends the form back before anyone reads the security content.

Data flows and hosting

Name the countries. An answer saying data is hosted securely in the cloud generates a follow up every time. State the hosting provider, the region, whether any replica or backup sits elsewhere, and whether staff outside that region can reach production. If your engineers in Armenia access an EU hosted environment, disclose it here; the customer’s transfer analysis depends on it, and discovering it later costs you credibility on every other answer you gave.

Subprocessors

Name every entity, including the ones that feel invisible: ticketing, error monitoring, transactional email, analytics, and payroll platforms that touch customer contact data. Article 28(2) of the GDPR requires the customer’s prior authorisation for engaging a new subprocessor, so the register needs a change notification commitment beside it, with a notice period and an objection right the customer can actually exercise.

Breach and incident notification

Your contract will carry a notification window running to the customer. Commit only to a window your on call rota can meet on a Saturday night, because the customer’s own 72 hour clock under GDPR Article 33 starts when it becomes aware, and it will push that pressure down the chain to you.

Armenian regulatory notification is a separate question, and the first thing to establish is your own size. Armenia’s Law on Cybersecurity, HO-442-N, is not confined to operators of critical infrastructure. Article 1(3)(1) catches a legal entity or individual entrepreneur that both works in one of the sectors listed in Article 16(4) and operates an information system or critical information infrastructure. Those are two limbs, not one. Information technology, expressly including digital infrastructure, is Article 16(4)(9); database management and operation is Article 16(4)(12). Neither point is limited to infrastructure operators, and there is no exemption for a supplier whose clients are all foreign. The common answer, that the company does not run critical infrastructure, therefore does not dispose of the question.

The exclusion that does dispose of it for many suppliers is Article 1(4). An entity meeting the micro or small enterprise criteria falls outside the law altogether, unless it operates critical information infrastructure. Under Article 2(1) of the Law on State Support to Small and Medium Entrepreneurship the small enterprise criteria are an average listed workforce of up to 50 and previous year revenue, or previous year end balance sheet assets, not exceeding AMD 500,000,000. A great many Armenian development and BPO companies sit inside that exclusion. It turns on your own headcount and accounts, so settle it before you answer the questionnaire.

If the exclusion does not cover you, the duties sit in Article 11. Notify the Autonomous Body, the Information Systems Regulation Commission, immediately on becoming aware and in any event within 24 hours, where the incident has significant impact or such impact can reasonably be presumed. Article 11(2) defines significant impact, so not every minor incident triggers a report. Updated information on severity and consequences follows within 72 hours of becoming aware. That clock runs from awareness, not from the first notification, which is a distinction worth getting right in the contract as well. Potentially affected persons are notified immediately, or within two days where immediate notice is impossible, and a final report is due within one month of the 72 hour submission.

Whether those duties bite today is contested. The law entered into force on 4 January 2026, but Article 25(1)(2) postpones the general notification obligation in Article 9(3)(5) until the corresponding secondary acts enter into force, and those acts have not been published. Article 11 is not expressly postponed, and nothing published resolves the tension. The Government has also still to adopt the service classifications under Article 16(5) that would tell a particular supplier whether it is caught. Prime Minister’s Decision N 117-A of 13 February 2026 schedules those classifications for 21 to 30 November 2026, with the list of identified critical infrastructure operators to follow in December. Those are scheduled dates, not adopted instruments.

Three things follow. Do not draft a contractual notification clause on the premise that no Armenian regulatory duty exists. Do not treat absence from the Commission’s register as a safe harbour, because on the better reading of Articles 1 and 3 the register kept under Article 7(4) records status rather than creates it. And diary the November classifications, because they are what will settle your position.

Retention and deletion

Give a schedule by data category, with the event that starts each clock. Then state what happens at termination: return in a named format, deletion within a stated number of days, and what remains in backups until the backup cycle overwrites it. Backup residue is the answer most suppliers get wrong, by promising immediate deletion their architecture cannot perform.

Access control and personnel

Cover role based access with named approvers, multi factor authentication on production systems and on the identity provider, joiner and leaver timing in working days, and the confidentiality undertakings in your employment contracts. Where a screening step the questionnaire assumes is not available to you, say so plainly. A customer can work with a documented constraint and cannot work with a vague answer.

Frequently asked questions

Where to start

1. Ask the customer which of its legal entities is the controller and which categories of personal data will actually reach you. Scope narrows the questionnaire before you answer a single item.
2. Build the subprocessor register first. The data processing agreement, the transfer paperwork and the data flow answers all depend on it.
3. Confirm with the customer which standard contractual clause module fits the relationship, which turns on whether the customer acts as controller or as processor for its own client.
4. Have the data processing agreement reviewed against the Armenian written instruction requirement before signature, so one document carries both obligations.
5. Settle your position on Armenian cybersecurity notification for your own operations before agreeing a contractual notification window.

Last updated: 21 September 2026