GDPR Information Notice

1. What this notice is

This is the information Articles 13 and 14 of Regulation (EU) 2016/679 (the GDPR) require the controller to give you. It is not a consent form and there is nothing here to agree to: you are being told how your personal data is handled, and you are asked only to confirm that you have read it.

Article 13 applies to an address you typed yourself when you opened your account. Article 14 applies as well where we did not get your email address from you: an address that reached us on a matchmaking-group roster YASAD supplied, which is how an invitation reaches you in the first place.

2. Controller

Yazılım Sanayicileri Derneği (YASAD) — the Turkish software industry association — of [YASAD postal address], Türkiye. Site: yasad.org.tr. Contact for anything in this notice: connect@yasad.org.tr.

YASAD determines the purposes and means of the processing described here and is therefore the controller.

Processor. Internative (internative.net) designs, builds, hosts and operates YASAD Connect for the association, voluntarily and free of charge, acting on YASAD's instructions. Internative also holds a seat on YASAD's audit board (denetim kurulu). We disclose that relationship because you are entitled to know that the technical operator and a member of the association's audit body are the same house. The iOS listing is published under an Apple Developer account belonging to Internative Yazılım A.Ş.

Article 27 representative. YASAD has no establishment in the European Union, and no representative in the Union has been appointed to date. If the association's offering to data subjects in the Union brings it within Article 3(2), a representative must be appointed under Article 27, and this notice will then name them.

Data protection officer. None appointed. YASAD is not a public authority, the processing is not large-scale monitoring, and no special categories of data are processed.

3. Categories of personal data

Identity and contact data. Name, email addresses (one or more per account, with verification state), and where you supply them a mobile number, a landline and its extension.

Professional profile data. Title, biography, photograph, LinkedIn address, interests, topics, company and company logo, matchmaking group membership.

Relationship and content data. Connection requests and connections, blocks placed, message content, meetings and their notes, the short-lived token minted when you export an accepted meeting to your own calendar, the 24-hour token minted when you create a share link to your own card or your company's, the short-lived token minted when you export another member's card to your address book — which records which account asked, because the content of the file depends on the reader — notification preferences, account status and — where an account has been suspended — the date and the operator's stated reason.

Support correspondence. The free text of a support request you send from inside the application, when you sent it, and the administrator's reply.

Account-deletion data. If you ask us to delete your account: the date of the request, the date thirty days later on which it is set to complete, its status — scheduled, cancelled or completed — the dates of a cancellation or a completion, and the free-text reason you may optionally give. This record is retained after the account it concerns is gone, and section 8 states the basis for that.

Moderation data. A report one member files about another member or a company: the reason chosen, the reporter's own written account, and a snapshot taken at filing time of how the reported profile then read — name, title, company or sector, image address, and the matchmaking groups the two shared. Then the outcome: status, decision, deciding administrator, time, and that administrator's note. This is a category of a kind the rest of this notice does not contain: personal data about you written by somebody else. It is held because a closed professional venue that cannot receive a complaint cannot act on one. No message thread is attached to a report and the schema has no field for one — the reporter may quote what they wish inside their own statement, but the system does not hand an operator the conversation.

Audit-log data. Every write made in the administration panel, and every sign-in to it: the acting administrator's account, email address and name at the time; the action; the record's type, identifier and label; the before and after values of the fields that changed; the request, its status and its duration; and the administrator's IP address. The recordable fields are fixed by a closed allow-list in the code — message content, conversation content, a meeting's private note, an organiser's roster notes and a member's own profile fields are absent from it and cannot enter a row. A member appears in the log only as the subject of an administrator's action. Rows are append-only and are never updated.

Technical data. IP address in web-server access logs, request metadata, rate-limiting counters, failed-sign-in counters and the temporary block record that follows them (IP address, or IPv6 address block, and no account identifier), session identifiers, push device token and account identifier held by the push provider.

Bot-protection data. For anyone who opens the administration panel's sign-in screen: the IP address, user agent and behavioural browser signals that screen discloses to Cloudflare Turnstile, plus the irreversible hash of the one-time verification token our server keeps briefly so the same token cannot be used twice. This processing does not occur in the mobile application.

No calendar or address-book data. Granting the calendar permission lets the application read and write entries on your device; none of it is transmitted to us, and there is no record of it anywhere in our systems. The contact export asks for no address-book permission and reads nothing from it.

No special categories. The product has no field for health, biometric, religious, political, trade-union or comparable data, nor for identity-document or financial details. Please do not put such data into a free-text field, where it would be processed without a lawful basis chosen for it.

4. Source of data not obtained from you (Article 14)

Your email address, and usually your name, your company and the group you belong to, come from a matchmaking-group roster supplied by YASAD and imported into the system before your first sign-in. YASAD compiles those rosters from its own membership and event records and from the organisations taking part in a given matchmaking programme. No data broker, no public scraping and no purchased list is involved.

Everything else in your profile comes from you, or is generated by your use of the service.

5. Purposes and lawful basis

Each purpose below is stated with the Article 6(1) basis relied on for it.

• Inviting you and holding the roster before you have an account — Article 6(1)(f), the legitimate interests of YASAD and of the inviting organisation in running a matchmaking programme for a defined professional community. You may object under Article 21 at any time, and an objection at this stage ends the processing.
• Creating your account, signing you in by one-time code, and providing the networking service — Article 6(1)(b), performance of the contract constituted by the Terms of Service.
• Showing you group-scoped people, companies and content, and carrying your connections, messages and meetings — Article 6(1)(b).
• Receiving and answering a support request you send us — Article 6(1)(b); you addressed it to the association and answering it is part of providing the service.
• Exporting an accepted meeting to your own calendar when you ask for it — Article 6(1)(b). This covers both routes: the device-calendar permission, whose reading and writing happen on your phone and produce no processing by us at all, and the ten-minute calendar link for members who decline it.
• Letting you show your own card, or that of a company you belong to, to somebody outside the product through a short-lived link you create — Article 6(1)(b). Only the subject can create the link: no other member can publish you, and a company's link can be minted only by its own people.
• Letting a member you are connected to export your telephone numbers and primary email address into their address book — Article 6(1)(a), consent. It is a single, specific, freely given switch that is off by default, it is described in plain terms before it is offered, refusing it costs nothing (the file is simply written without those fields), and you may withdraw it at any time under Article 7(3) — with the limit any consent of this shape has: withdrawal stops future exports and cannot recall a card already in somebody's address book, which is stated in the settings screen as well as here.
• Suggesting members you might usefully meet — Article 6(1)(f), our legitimate interest in making the service work as a matchmaking product, balanced by the fact that a suggestion is visible only to you and changes nothing about your account. Section 11 describes the ranking itself.
• Receiving reports members file about each other, deciding them, and suspending an account where that is the decision — Article 6(1)(f), the legitimate interest of the association and of every member in a venue where unacceptable conduct can be raised and acted on. The balancing runs like this: what is processed is the reporter's own statement rather than a copy of anyone's conversation, which is why no thread is attached; the record is read only by the operators who will decide it; the outcomes are three and no action is the first of them, a real result rather than a failure to punish; and the alternative is an association with no answer at all for a member being harassed by another. A suspension is told to the person suspended, with its reason, which is the point at which they can contest it.
• Recording what administrators do in the panel — Article 6(1)(f) and, as to the accountability the Regulation itself imposes, Articles 5(2) and 24. The interest is being able to show afterwards how administrative authority over members' data was used, which serves the members it was used on. The processing is kept to the minimum that serves it: a closed allow-list of fields, an IP address that belongs to the administrator and not to any member, rows that cannot be altered once written, and a fixed two-year life after which the row is gone whether or not anyone read it.
• Acting on your request to delete your account, and holding it open for thirty days so you can change your mind — Article 6(1)(b) for carrying out the request itself, which is you exercising your side of the contract, and Article 6(1)(c) as to the erasure the Regulation obliges us to perform once there is no longer a basis to hold your data. The optional reason you may write is not needed for either and is processed on Article 6(1)(a), consent: leaving it blank changes nothing about the request, its date or its outcome.
• Keeping the record of a deletion after the deletion — Article 6(1)(f), and Article 5(2) as to accountability. The interest is being able to show that an erasure was requested and carried out, on the date it was promised; a record that erased itself along with everything else would leave the association unable to demonstrate compliance with the very right it was honouring. What is kept is the request, not the person: dates, a status, and your own words if you wrote any.
• Sending service email — the one-time sign-in code, invitations and meeting notices — Article 6(1)(b). These are transactional messages, not marketing.
• Sending push and email notifications about messages, connection requests, meetings, announcements, company requests, group membership, support and moderation — Article 6(1)(b). Nine categories, each with its own push switch and its own email switch, all of them on until you say otherwise, and your device's own settings on top of that.
• Security, rate limiting, abuse investigation and fault diagnosis — Article 6(1)(f), the legitimate interest in a service that stays available and is not abused.
• Distinguishing a person from an automated client at the administration panel's sign-in screen (Cloudflare Turnstile) — Article 6(1)(f), the legitimate interest in an administrative sign-in that cannot be attacked by a script. The balancing point is that the data involved is technical rather than substantive, it is processed only at the moment of signing in to the panel, it is never used to profile or to make a decision about anyone, and the alternative — leaving the association's administrative door open to automated attempts — is a worse outcome for every member whose data sits behind it.
• Complying with obligations that bind YASAD, and establishing or defending legal claims — Article 6(1)(c) and Article 6(1)(f).

Providing the roster data is a precondition of being invited; providing your optional profile fields is not, and leaving them empty costs you only visibility inside your groups.

6. Recipients and processors

Other members of your matchmaking groups see your name, title, biography, LinkedIn address, photo, interests, topics, primary company, shared groups, the tag the association gave you in each of those groups (investor, attendee, exhibitor, for instance) and connection status. No screen in the product shows them your email address or your telephone numbers. Members outside your groups see nothing — except what you hand them yourself, below.

A member you are connected to, where you have consented, additionally receives your telephone numbers and your primary email address as a contact file, for their own address book. Both conditions — your opt-in, which is off by default, and an accepted connection — are enforced on the server, when the link is minted and again when the file is fetched.

Anyone holding a share link you created receives the reduced card: name, title, company name and photo address, or for a company its name, logo, sector, city, country and website. Nothing else, for 24 hours, at an address published nowhere and marked not to be indexed. This is a disclosure you initiate; no other member can initiate it about you.

YASAD administrators see identity, linked email addresses and their verification state, group memberships, companies, connections, and meetings — status, type, time, place, participants, group — but not a meeting's private note. No administrative screen exposes message or conversation content.

Processors and onward recipients:

• Cloudflare — object storage (R2) for profile photos and company logos only, in a private bucket.
• Cloudflare — Turnstile bot protection on the administration panel's sign-in screen. A separate service and a separate disclosure from R2: the browser opening that screen contacts Cloudflare directly and discloses its IP address, user agent and behavioural signals, and our server sends Cloudflare the one-time token for verification. Not used in the mobile application.
• OneSignal (United States) — push delivery. It receives your account identifier, your device push token and the notification payload, which carries the sender's full name and up to 140 characters of message text. OneSignal passes that payload on to Apple (APNs) or Google (FCM) to reach your device.
• Google — the mobile application fetches its typefaces from Google Fonts at runtime, disclosing your device's IP address and user agent to Google.
• Google — the Maps SDK draws the venue and address picker's map, disclosing your device's IP address with each map request. Google's disclosure for that SDK also lists crash, performance, in-app interaction and device-identifier data collected for analytics; it does not reach us, and Google states it is not used for tracking. Location is not in that list.
• Contabo — the hosting provider of the single server on which the service, its database and its cache run.

Email is not sent through any third-party provider. Messages leave through YASAD's own relay at mail.yasad.org.tr, under the association's own address.

Moderation records and audit-log rows go to no third party at all. They stay on the association's own server and are read only by its administrators.

Your calendar service is your recipient, not ours. When you export an accepted meeting, the entry goes to your device and then to whichever calendar you save it in, on your initiative; what that provider does with it is governed by its own terms. It carries the meeting's time, its place if one was given and the other participant's name — not the private note, and not an email address. This is true of both routes, and where the calendar permission is granted we are not a party at all: the write happens on your device and we never learn that it occurred.

Your address book is likewise your own. A card you export lands on your device and syncs wherever that device syncs. We are not a recipient of it, and we cannot withdraw it afterwards.

7. Transfers outside the EEA, and the safeguards relied on

The service does not run inside the EEA at all, so if you are in the Union your data is transferred abroad from the moment you use it. The transfers are these.

• United Kingdom. The server is operated by Contabo in London, and the database, the cache and the access logs live on it. Transfers to the United Kingdom currently rest on the European Commission's adequacy decision for the UK, under Article 45. If that decision lapses or is withdrawn, the transfer must move onto standard contractual clauses under Article 46(2)(c).
• Türkiye. YASAD is established in Türkiye and its administrators work with your data from there; the association's mail relay is likewise Turkish. There is no adequacy decision for Türkiye. These transfers therefore need an Article 46 safeguard — in practice standard contractual clauses between the association and its processors — or, for the narrow case of running the service you asked for, Article 49(1)(b). Article 49 covers occasional transfers, not the routine operation of a platform, so an Article 46 safeguard is what this processing requires rather than the derogation.
• United States. Push notifications reach OneSignal, and onward Apple and Google. The safeguard for each of the three is either that provider's certification under the EU–US Data Protection Framework or the standard contractual clauses in its terms.
• Cloudflare Turnstile. Opening the administration panel's sign-in screen discloses that browser's IP address and signals to Cloudflare, and our server's verification call goes to the same place. Cloudflare answers from whichever edge location is nearest, so this is a transfer whose destination country is not fixed. Cloudflare's standard data-processing addendum incorporates the standard contractual clauses under Article 46(2)(c), and Cloudflare is certified under the EU–US Data Protection Framework.
• Google Fonts. The runtime typeface request discloses your IP address to Google's servers, wherever they answer from. It can be removed by shipping the fonts inside the application, which is the cleaner fix.
• Google Maps. Map requests, and the analytics data Google's own SDK disclosure lists, go to Google's servers wherever they answer from. Unlike the fonts this one cannot be removed by bundling anything: a map is a service. Google's terms incorporate the standard contractual clauses under Article 46(2)(c), and Google is certified under the EU–US Data Protection Framework.

You may ask us for a copy of the safeguards relied on, at the contact address above.

8. Retention

Nothing about you in the main database expires with age. Your account, profile, messages, connections, meetings, support requests and the reports filed about or by you — decided ones included — are held until a person removes them. There is no age-based deletion rule over member data, and we would rather say so than publish a retention schedule the product does not enforce.

The exception is the one you control: deleting your account. The request schedules the erasure for thirty days later. During those thirty days nothing is destroyed, you are hidden from every member-facing screen, and you may cancel — including by signing in, which remains possible for that purpose alone. On the thirty-first day the erasure completes and is irreversible: profile, privacy and notification preferences, the email addresses on the account and its group memberships are removed. Four things outlive it, each for a stated reason: messages already delivered, which are also the other participant's personal data and are held on the legitimate-interests basis in their favour; your acceptances of these texts, held under Article 6(1)(c) and 6(1)(f) as the proof of what was agreed and when; records needed to establish, exercise or defend a legal claim, the Article 17(3)(e) limit on erasure; and the deletion request itself, whose retention is described in section 5.

What does expire: the one-time sign-in code after 10 minutes; a meeting's calendar link after 10 minutes; a contact-export link after 10 minutes; a share link after 24 hours; a session access token after 15 minutes; a session refresh token after 30 days; web-server access logs, including your IP address, after 30 days; the failed-sign-in counter after at most 10 minutes, or immediately on a successful sign-in from the same connection; the temporary block that counter can open after 15 minutes, which further attempts do not extend; and the irreversible hash of a bot-protection token after 5 minutes, the token itself never being stored.

The audit log is the one record whose retention period is enforced by its own age, and it is about administrators. Each row is deleted by the database 730 days — 24 months after it was written. The period is a constant in the source, not a deployment setting, so shortening or lengthening it is a visible change rather than a quiet one; it is long enough for the association's own annual review and for a complaint that arrives months after the act it concerns, and short enough that a control does not become a second permanent store of people.

That period does not conflict with the 30 days stated above for access logs, because the two records are different. The access log covers every request, and therefore every member's IP address; it is deleted after 30 days. The audit log covers only administrative writes and panel sign-ins, and its IP address is the administrator's. No member's IP address is held for 24 months. A member enters that log only as the subject of an action, through the allow-listed fields of that action.

The brute-force counter and the block are processed on the legitimate-interests basis, Article 6(1)(f). The interest is keeping an invitation-only roster from being brute-forced one code at a time; the processing is the minimum that serves it — an IP address (or IPv6 /64), no account identifier, and a maximum life of fifteen minutes, after which the record is gone whether or not anybody looked at it.

One retention behaviour is worth naming. A failed outgoing email is kept in the queue for inspection and still contains the body it was to send, which for a sign-in message includes the one-time code. The code is unusable after 10 minutes; the record is not cleared on a schedule.

9. Your rights

Under Articles 15 to 22 you have the right to:

• Access (Art. 15) — obtain confirmation that we process your data, a copy of it, and the information in this notice.
• Rectification (Art. 16) — have inaccurate data corrected and incomplete data completed. Most profile fields you can correct yourself in the application.
• Erasure (Art. 17) — have your data deleted where one of the Article 17(1) grounds applies. For your account as a whole you do not have to ask us: the application deletes it, on a thirty-day schedule you can cancel from, and section 8 sets out what completes and what survives. Message content already delivered to another member, a report another member wrote about you together with its decision, and records we must keep to defend a legal claim, are the usual limits — as is the record of the deletion request itself.
• Restriction (Art. 18) — have processing limited while an accuracy dispute or an objection is resolved.
• Portability (Art. 20) — receive the data you gave us, in a structured, machine-readable form, for the processing based on contract.
• Objection (Art. 21) — object at any time to processing based on legitimate interests, including the roster invitation and the matchmaking suggestions.
• Withdraw consent — where processing rests on consent: the contact-export switch in section 5, and the optional reason on a deletion request. Notifications you control instead through the nine per-category switches in the application and through your device's own settings.

How to exercise them. Deleting your account is done in the application and needs no request to us. For everything else, write to connect@yasad.org.tr: there is at present no self-service export, so a person handles it. We will respond within one month of receiving it, extensible by two further months for a complex request, and we will tell you if we need the extension.

10. Complaints

If you believe your data has been handled unlawfully you may lodge a complaint with a supervisory authority under Article 77 — in the Member State where you live, where you work, or where the alleged infringement took place. Doing so does not affect any other remedy, and you do not have to raise the matter with us first, although we would rather you did.

11. Automated decision-making and profiling

There is no automated decision-making producing legal effects, or similarly significant effects, on you within the meaning of Article 22(1). No algorithm in this product grants or refuses you access, admits or removes you from a group, or decides anything else about your standing.

We should nevertheless describe the ranking honestly, because it is profiling in the Article 4(4) sense.

The comparison runs only over terms you and the other member each declared about yourselves, and it looks for five kinds of overlap: a service they offer that you said you need, a service you offer that they said they need, a shared partnership interest, a shared topic you both said you want to talk about, and a shared interest. Nothing else is fed in — not your messages, not who you met, not how often you open the app. Where nothing overlaps, no suggestion reason is produced at all.

Those overlaps also produce a number, and the number is only a sort key: it is shown to nobody — not to you and not to the person ranked. What you are shown is the *reason* — which of your own terms matched theirs — because a score you cannot check is a claim you cannot argue with.

The ordering is a suggestion shown only to you. It does not filter anyone out of the directory, it is not shown to the person being ranked, it does not affect their account, and either of you may ignore it entirely. It has no legal effect on anyone, which is why Article 22 is not engaged. You may still object to it under Article 21, and we will stop ranking for you.

12. Changes to this notice

Every version of this notice is kept, numbered and dated. When a materially new version is published you will be shown it the next time you open the application, and we record which version you read and when.