Cyprus Startup GDPR: A Practical Company Checklist

Start with the company’s real data flows

List the activities that involve identifiable people: enquiries, customer accounts, billing, recruitment, payroll, support, marketing and website measurement. Include information about business contacts even where customers are companies. A named employee’s email address or an identifiable user’s support history can involve personal data. The fact that the business sells to other businesses does not remove the need to examine the people appearing in its records.

Walk through a sample transaction from collection to deletion. For an enquiry, identify the website form, email delivery, CRM, adviser access and eventual archive. For payroll, identify the employee records, payroll provider, payment process and statutory records. Include spreadsheets and shared drives that sit outside the main system. This practical map often reveals copies and access permissions that a generic policy would miss.

Use the EDPB small-business guide as an official starting point. The legal framework is the General Data Protection Regulation. This article organises an implementation exercise for founders; it does not certify compliance or replace assessment of the company’s particular processing, sector and cross-border arrangements.

Identify controller and processor roles per activity

A company deciding why and how personal data is processed acts as a controller for that activity. A provider processing personal data on another organisation’s behalf under instructions may act as a processor. The EDPB role guidance explains these distinctions, including joint controllers and subprocessors. Apply them to the facts rather than choosing a label because a contract template uses it.

A software startup can be a controller for its own staff and billing contacts while processing some customer-uploaded information on a customer’s behalf. The answer may differ across product features. If the startup decides to reuse customer data for its own separate purpose, that decision needs its own assessment. Do not assume a single label attached to the company resolves every flow through the product.

Record the reasoning and the corresponding responsibilities. Where processing is on behalf of a customer, examine the instructions, assistance obligations, subprocessor arrangements and security commitments. Where the company is controller, ensure it can explain the purposes, lawful bases and relevant disclosures. The software and SaaS company guide covers the broader business structure; the data-role analysis remains specific to the service and its operation.

Choose lawful bases and collect only what is necessary

For each processing purpose, assess the appropriate lawful basis under Article 6. Contractual necessity, legal obligations, legitimate interests and consent are distinct bases with their own conditions. Do not ask people to “consent to GDPR” as a substitute for identifying the purpose and basis. Consent is not a universal solution for employment records, statutory bookkeeping or every action required to deliver a service.

Where legitimate interests are considered, assess and document the purpose, necessity and balance against individuals’ rights and interests. Where consent is relied on, design a genuine choice and a working withdrawal process. Special-category information and criminal-offence data require additional analysis beyond selecting an Article 6 basis. Avoid collecting sensitive information merely because a template contains a convenient field.

Review each form field against the stated purpose. If an initial service enquiry needs a name and email address, consider whether a passport scan is really necessary at that stage. Later regulated onboarding may involve different obligations and a separate secure process. The source-of-funds and KYC guide addresses evidence preparation; it should not be used to justify collecting every possible document from every website visitor.

Write notices that match what the business does

Articles 13 and 14 of the GDPR set information requirements, with the applicable details depending on how the data is obtained. Prepare notices from the inventory rather than copying another company’s website. Identify the correct company, purposes, bases, recipients, relevant transfers, retention information and rights, together with the other required details. Make the information accessible at the appropriate stage of collection.

Different audiences may need different explanations. A customer enquiry notice, employee notice and product-user notice can share a consistent approach while describing different activities. Do not promise that data is never shared if hosting, payroll or support providers receive it. Do not promise immediate deletion of all records where applicable legal retention obligations require some information to remain.

Treat cookies and similar technologies as a separate factual and legal review alongside GDPR. Inventory what the site actually loads and assess applicable electronic-communications rules and consent requirements. A banner that says “we value privacy” is not evidence that scripts follow the user’s choice. Test collection and withdrawal behaviour, keep the wording accurate and remove tools the company does not need.

Put supplier contracts and transfer arrangements in place

For processors, Article 28 requires an appropriate binding arrangement covering specified matters. Review the actual supplier terms, processing instructions, confidentiality, security, assistance, deletion or return and subprocessor arrangements. A supplier’s marketing claim of compliance is not the same as a contract that fits your use. Keep the accepted terms and version date rather than relying on a web page that can change without a local record.

Identify where personal data is processed and accessed, including support and subprocessors. A billing address or an “EU hosting” label does not necessarily describe every access route. Where transfers outside the EEA arise, assess the applicable Chapter V mechanism and any necessary additional evaluation or safeguards. Do not assume that an ordinary commercial confidentiality clause alone resolves an international-transfer requirement.

Create a supplier review proportional to the activity. A provider handling highly sensitive customer records warrants different attention from a tool receiving only limited business-contact information. Record the decision, contractual protections and any open conditions. If the company changes a supplier or adds an integration, revisit the data map before enabling production access. This is a practical procurement control, not an exercise to complete only after a customer asks questions.

Implement security, retention and access controls

Article 32 requires security appropriate to the risk. Translate that obligation into controls the team actually operates: named accounts, appropriate permissions, strong authentication, managed devices, patching, backups and secure sharing. The right measures depend on the data and processing. A policy declaring encryption is used does not help if staff routinely send unprotected files to personal accounts outside the approved workflow.

Test access removal when staff and contractors leave. Identify system owners and recovery routes so that one departing administrator cannot leave the company unable to manage its records. Restrict production access to the people who need it and review privileged roles. Keep an appropriate audit trail for material changes without indiscriminately collecting additional personal data simply because a tool can log it.

Set retention rules by category and purpose, taking relevant legal obligations into account. Define what happens when the period expires and how deletion or restricted archival storage works across copies and backups. Avoid one blanket period for every document. Payroll records, unsuccessful enquiries, account data and security logs can have different purposes and requirements. Coordinate employment records with the payroll records guide and professional advice on applicable retention duties.

Prepare for access, correction and deletion requests

Assign a contact route and train the team to recognise a rights request even if it does not use legal terminology. Record when it arrived, what is requested and which systems may contain relevant information. Verify identity proportionately; requesting excessive identity documents for every simple enquiry can create another data-protection problem. Escalate ambiguity rather than leaving the message unanswered in a general inbox.

Under Article 12, respond without undue delay and ordinarily within one month, with a possible further two months where the specified conditions apply, and the individual must be informed within the first month of an extension and reasons. Do not rewrite this as a universal 30-day rule or assume every difficult request permits delay. Assess applicable rights, exceptions and the actual circumstances, retaining a reasoned record.

Deletion is not always unconditional. The company may need to retain particular information for a legal obligation or another applicable exception while stopping unrelated uses. Explain the decision accurately. If a customer asks to delete an account, check connected services and processors instead of merely hiding the account in the interface. Keep a record sufficient to demonstrate the response without retaining unnecessary copies of everything deleted.

Create a breach response before the first incident

A personal data breach can involve confidentiality, integrity or availability; it is not limited to a publicly exposed database. A misdirected attachment, lost device or unavailable records may require assessment. The EDPB breach guide explains the controller’s notification duties and the processor’s duty to inform the controller without undue delay. Set an internal escalation route that works outside the founder’s ordinary working hours.

Article 33 requires notification to the relevant supervisory authority without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. Reasons are required where notification is late. Article 34 separately addresses communication to affected individuals where high risk arises, subject to its conditions and exceptions. Not every technical incident triggers the same notification outcome.

Document the facts, awareness time, affected data, likely consequences, containment actions and notification assessment. Do not wait for a perfect forensic report before considering a time-sensitive obligation. Preserve useful evidence and coordinate technical, legal and management responses. An incident log should also capture the reasoning where notification is not required. Test the process with a realistic exercise so that the first actual incident is not the first time anyone looks for the contact list.

Assess records, a DPO and high-risk processing

A small workforce does not create a general GDPR exemption. Article 30’s recordkeeping derogation for organisations with fewer than 250 employees has important conditions, including processing that is not occasional, relevant risk and certain data categories. Regular customer or staff processing should not be dismissed merely because the company is a startup. Maintain a useful processing inventory and assess the specific legal recordkeeping requirements.

A data protection officer is not automatically mandatory for every Cyprus company. Article 37 identifies circumstances including relevant public-body processing and certain core activities involving large-scale monitoring or large-scale processing of specified sensitive data. Assess the actual activities, independence and conflicts of interest. Naming the founder “DPO” without considering the role and conflicts is not a substitute for this assessment.

Where processing is likely to result in high risk, assess the need for a data protection impact assessment under Article 35 before implementation. Examples needing careful evaluation can include extensive monitoring, sensitive information or novel processing with significant effects on individuals. Do not treat an ordinary risk checklist as automatically equivalent to a completed DPIA. Seek qualified input and consider the competent authority’s relevant guidance and lists.

Run a practical startup implementation review

Take an illustrative startup with an enquiry form, a hosted product, two employees and an external accountant. Its first review maps each flow and separates product processing from its own staff and sales records. It then aligns notices, contracts and permissions with those flows. This example is a planning exercise, not a finding that all companies with that profile have identical legal obligations.

• Assign a responsible person for the data inventory and unresolved questions.
• Check purposes, lawful bases, necessary fields and audience-specific notices.
• Review processors, transfers, access roles and actual security settings.
• Set retention and rights-request procedures that staff can carry out.
• Prepare incident escalation and assess DPO, records and DPIA requirements.
• Retain evidence of the decisions and review changes before adding new processing.

Include these responsibilities in the post-incorporation handover, with owners and next actions. Review privacy when the company hires, changes suppliers or launches a new feature, not only when it refreshes its website. The useful outcome is an operating process that matches the business, backed by accurate documents and a clear route for specialist assessment where the facts require it.