The security workshop
It always lands at the same point in the sales cycle. The technical part is done, the architecture holds up, the team goes down well. Then they sit you in front of the CISO and the conversation changes character.
The question I was asked was not "are you ISO 27001 certified". It was "show me how you work".
That distinction matters. A certified customer does not need you to be certified. They need to prove to their auditor that they control what you do with their data. Their certificate is on the table, not yours.
Plenty of suppliers miss that step. They prepare a sales answer to an audit question.
You are a control inside their system
Here is the reversal.
Annex A of the standard contains a control called A.8.30, Outsourced development. From their side of the table, the outsourced development is you. When the auditor opens that line, they are not reading your capability deck. They are looking at your code reviews, your security testing, your development lifecycle.
Your SDLC is their audit evidence. No records on your side, no evidence on theirs.
Five Annex A controls deal specifically with suppliers:
- A.5.19 Information security in supplier relationships
- A.5.20 Addressing information security within supplier agreements
- A.5.21 Managing information security in the ICT supply chain
- A.5.22 Monitoring, review and change management of supplier services
- A.5.23 Information security for use of cloud services
A small notation trap gives away anyone copying without reading. ISO 27001 writes A.5.19, with the Annex prefix. ISO 27002, which carries the implementation guidance, writes 5.19 without it. And you cannot be certified against 27002 at all. It explains the how, it is not the auditable part.
What the customer has to demonstrate comes down to four things: that they assessed you before signing, that the contract covers the right subjects, that they monitor delivery over time, and that their requirements reach your own subcontractors.
The subject that actually blocks deals
On our engagements, application security is never what stalls things. It is GDPR.
The team is in Rabat, the customer is in Europe. The reflex answer from suppliers: "the data stays in the EU, the code is simply written in Morocco".
That answer does not hold. EDPB Guidelines 05/2021 are explicit. Remote access from a third country is a transfer, even where it goes no further than displaying personal data on a screen, including in support or administration situations. A transfer is not measured by where the disk is plugged in. It is measured by who can see what, and from where.
European hosting is an excellent risk reduction measure. It is not a Chapter V answer.
So you need a legal basis. Morocco does not appear on the European Commission's list of adequacy decisions. The basis is Article 46(2)(c), the standard contractual clauses of Decision (EU) 2021/914.
And here is the detail almost everyone gets wrong: the module. Many suppliers sign Module Two, controller to processor. In a structure like ours the Belgian entity is already a processor and the Moroccan entity is a sub-processor. That is Module Three, processor to processor.
Signing the wrong module produces a document that does not describe the relationship it is supposed to govern.
One last point here. The transfer impact assessment is not an optional good practice. Clause 14(d) of the SCCs commits the parties to document the assessment and make it available to the competent supervisory authority on request. It is contractual. If you signed, you owe it.
On the Moroccan side, Law 09-08 remains the framework in force and governs transfers abroad through its Articles 43 and 44. It does not create adequacy and it does not remove the SCC requirement. It does count in your favour in the Clause 14 assessment.
Test data, where it actually hurts
Control A.8.33 covers test information. It is the one that changes a team's habits most.
No production personal data in development or in staging. Ever. The temptation never goes away, because a real dataset reproduces cases nothing else reproduces.
What goes in its place:
- synthetic data generated to cover the edge cases
- pseudonymisation and masking where realistic structures are genuinely needed, which is control A.8.11
- the re-identification key held only by the European exporter
- a break-glass procedure for production support, logged and time-boxed
That last point is not cosmetic. EDPB Recommendations 01/2020 accept pseudonymisation, with the key retained inside the EEA, as a valid supplementary measure. It is the technical way out of the transfer problem, and it gets built in the code, not in the contract.
The 72 hour clock is not yours
Common mistake, easy to avoid.
Article 33(1) requires the controller to notify the supervisory authority within 72 hours. That deadline is not yours. Article 33(2) requires you, as processor, to alert the controller without undue delay, with no figure in hours anywhere in the Regulation.
Two practical consequences.
The 24 hour deadline you will be asked to sign is contractual, not statutory. Negotiate it knowing that.
And EDPB Guidelines 9/2022 state that the controller is considered aware the moment you have informed them. Your delay is taken out of their 72 hours. They also state that the processor does not need to assess the likelihood of risk before notifying. You report, they qualify.
What you can say when you are not certified
This is where a lot of suppliers burn themselves.
JADEV is not ISO 27001 certified today. It is a committed objective with a timeline. Until then, there are sentences we do not say.
Off limits:
- "ISO 27001 certified" when you are not
- "ISO 27001 compliant" unqualified, since compliance is what an accredited body attests
- the ISO logo, which ISO permits nobody to use in connection with certification, and ISO does not issue certificates itself
- "covered by our customer's certification", which corresponds to no formal notion at all
This is not excessive caution. Directive 2006/114/EC on misleading and comparative advertising between businesses expressly covers claims about the advertiser's qualifications, awards and distinctions. And a certificate takes seconds to check on the IAF CertSearch database.
Defensible, strongest first:
- "We operate an information security control set mapped to Annex A of ISO/IEC 27001:2022. We are not certified."
- "We maintain a Statement of Applicability covering the 93 Annex A controls, available under NDA."
- "aligned with" on its own: not deceptive, but it has no defined meaning and no evidentiary weight. Use it as support, never as the main claim.
In a security workshop it is the first formulation that works. It says what you do, it says what you do not have, and it lets the auditor verify.
The certificate is the customer's own internal work. Yours is to give them something they can defend it with.
Sources
- ISO/IEC 27001:2022, Information security management systems, 3rd edition, October 2022: [iso.org/standard/27001](https://www.iso.org/standard/27001)
- ENISA, Technical Implementation Guidance on cybersecurity risk management measures, v1.0, 26 June 2025, mapping controls A.5.19 to A.5.23: [enisa.europa.eu](https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance)
- Statement of Applicability published by Euronext Clearing, rev. 4.0, June 2025, a public example listing all 93 Annex A titles: [euronext.com](https://www.euronext.com/sites/default/files/2025-06/Euronext%20Clearing%20SoA%20-%20ISO%2027001%20-%20Public.pdf)
- European Commission, adequacy decisions, current list: [commission.europa.eu](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en)
- Implementing Decision (EU) 2021/914 of 4 June 2021, standard contractual clauses, modules and Clause 14: [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj/eng)
- EDPB, Guidelines 05/2021 on the interplay between Article 3 and Chapter V, v2.0, 14 February 2023: [edpb.europa.eu](https://edpb.europa.eu/system/files/2023-02/edpb_guidelines_05-2021_interplay_between_the_application_of_art3-chapter_v_of_the_gdpr_v2_en_0.pdf)
- EDPB, Recommendations 01/2020 on supplementary measures, v2.0, 18 June 2021: [edpb.europa.eu](https://www.edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measures-supplement-transfer_en)
- EDPB, Guidelines 9/2022 on personal data breach notification, v2.0, 28 March 2023: [edpb.europa.eu](https://www.edpb.europa.eu/system/files/2023-04/edpb_guidelines_202209_personal_data_breach_notification_v2.0_en.pdf)
- Regulation (EU) 2016/679, Articles 28, 32, 33, 34 and 44 to 46: [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- ISO, official page on certification and logo use: [iso.org/certification.html](https://www.iso.org/certification.html)
- IAF CertSearch, accredited certificate verification: [iafcertsearch.org](https://www.iafcertsearch.org/)
- Directive 2006/114/EC concerning misleading and comparative advertising: [eur-lex.europa.eu](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32006L0114)
- CNDP, formalities and the transfer regime under Articles 43 and 44 of Law 09-08: [cndp.ma](https://www.cndp.ma/formalites/)