GDPR obligations become operationally expensive when they run through email and spreadsheets. The compliant path is to run data-subject requests, consent management, and retention as native workflows on the CRM. Here is how Strkr handles each one.
GDPR has been in force since 2018 and most CRM operators still handle data subject requests through a combination of email, screenshots, and manual exports. The approach works at low volume. It breaks around the moment the first regulator inquiry arrives or the first class action pre-litigation letter lands. The gap between policy and practice is where compliance exposure lives, and the gap is almost always a workflow gap, not a legal one.
A data subject access request arrives via email to privacy@company.com. A privacy coordinator reads it, pastes it into a Jira ticket, searches four systems manually, exports what they can find to a PDF, redacts third-party references by hand, and ships the response at day 29. The next request lands two days later. The process does not scale and the audit trail is thin.
The right to erasure gets the contact deleted from the CRM main table. The CRM leaves records in the activity log, the email history, the integrated marketing automation tool, the backup system, and the data warehouse. The erasure is incomplete. If an audit traces the request, the gap is visible. The regulator sees a company that promised but did not deliver.
A contact opted in on a webform in 2022. The consent timestamp lives in a webform tool. The CRM has a boolean field "marketing OK" that nobody updates. The withdrawal of consent sent in 2024 was processed in the marketing automation tool but not synced back. The next campaign goes to the withdrawn contact. The complaint lands next week.
The CRM is hosted in Europe but the integrated analytics tool is US-based. Data flows from the CRM to US analytics without a documented transfer basis. The company has not completed the Transfer Impact Assessment. When the schrems-III-style enforcement arrives, there is no paper trail. The exposure is real and the documentation gap is operational, not legal.
A sales prospect who went cold in 2015 is still in the CRM in 2026 with their full history. The retention policy says 5 years post-last-activity. Nobody runs the retention script. The database is bloated with records the lawful basis has long since expired on. Every record is a potential breach vector and a potential DSAR surface.
The main CRM has a signed Data Processing Agreement. The email delivery tool, the calling tool, the enrichment vendor, and the AI note-taker often do not. When the regulator asks for the full subprocessor list and the DPA chain, the company produces three and discovers the chain breaks at the fourth. The GDPR Article 28 obligation lives on paper, not in practice.
GDPR is not a one-time project. It is an operational cadence: consent capture, lawful basis documentation, DSAR fulfillment, erasure execution, retention enforcement, transfer impact assessment, and incident response. Strkr runs each as a native workflow on the contact and account records so the obligations execute as the business operates, not as a side project.
Each contact record carries a Lawful Basis field with the six GDPR bases as options (consent, contract, legal obligation, vital interests, public interest, legitimate interests). The basis gets set at record creation based on the source (webform consent, contract signing, legitimate interest documentation). The field is required at creation and visible on the record.
The consent record carries the timestamp, the source (webform URL, event name, verbal consent note), the exact text the data subject agreed to, and the IP address if captured electronically. Consent is a record, not a boolean. Withdrawal creates a new consent record with the withdrawal timestamp. The full consent history lives on the contact.
An inbound DSAR request through the privacy intake form creates a DSAR record with the subject identity, the request type (access, rectification, erasure, portability, restriction, objection), the receipt date, and the response due date. Strkr auto-generates the data export from all linked records, flags fields requiring redaction, and tracks the response through to delivery. The 30-day clock is on the record.
An erasure request triggers a cross-system erasure flow: the main contact record, the activity log, the email history, the sync to marketing tools, the data warehouse export, and the archive snapshots. Each system reports confirmation back to the DSAR record. If a system cannot erase (legal hold, contract retention), the exception is logged with the basis. The audit trail is complete.
A consent withdrawal (an unsubscribe, a preference-center update, a direct request) propagates to the marketing module, the sync to any connected tools, and the next-campaign eligibility. The campaign that would send tomorrow sees the updated consent before send. The withdrawal is logged with timestamp on the contact. The audit shows the propagation times.
The retention policy is configured per record type and per lawful basis. A legitimate-interest prospect record with 5-year retention post-last-activity automatically transitions to pseudonymization at year 5 and full deletion at year 7 unless active legal hold applies. The nightly flow runs, the actions are logged, and the audit report ships quarterly.
The integration list carries each subprocessor with its hosting location, transfer basis (SCCs 2021, adequacy decision, derogation), and the TIA completion status. Transfers to non-adequate jurisdictions without SCCs are flagged on the admin dashboard. The DPO dashboard shows the subprocessor chain at a glance and the audit-ready documentation per vendor.
The admin interface tracks the signed DPA with each subprocessor, with the signing date, the counterparty, the Article 28 clauses included, and the renewal cadence. Subprocessors added without a signed DPA are flagged. When the regulator asks for the subprocessor list and the DPA chain, the inventory is one export away.
An incident flagged as a confirmed personal data breach starts a 72-hour clock to the supervisory authority notification. The flow surfaces the incident to the DPO, drafts the notification letter from the incident evidence, routes for legal review, and tracks the submission timestamp. The documentation stays on the incident record for subsequent regulator queries.
The 30-day DSAR response window is tight when the request has to pull data from six systems, redact third-party references, and format the response for a non-technical requester. Here is the workflow for the common DSAR types, and how Strkr handles each one. The workflow is the compliance; the policy is the paperwork.
A right-of-access request returns every piece of personal data held about the subject. Strkr generates the export from the contact record, activity log, email history, campaign enrollment, custom object relationships, and uploaded documents. The output is a structured PDF plus a machine-readable JSON archive. Third-party names and account references get flagged for redaction in a review step.
A right-of-rectification request updates incorrect data. The change happens on the record with an audit log entry (field changed, old value, new value, request ID, timestamp). The DSAR record tracks the fulfillment. The response to the data subject includes the fields updated, the fields that could not be updated with the basis, and the confirmation timestamp.
A right-to-erasure request fires the cross-system erasure flow. Each connected system (marketing, email, data warehouse, backup) gets the erasure call and confirms back. Records under legal retention (contracts, legal holds, specific regulatory retention) stay with the basis documented on the DSAR record. The response to the subject names which records were erased and which remain under what basis.
A right-to-portability request produces a structured JSON archive formatted to common CRM import schemas. The archive contains the subject-provided data (not derived data or inferences). The response includes the archive, the schema documentation, and the receiver guide for common target systems. The 30-day clock applies.
A right-to-restriction request stops active processing without erasing the records. Strkr marks the record Restricted, which disables marketing campaigns, outbound automation, and analytics inclusion for that contact. The record stays queryable for compliance. The restriction can be lifted by a documented decision when the dispute resolves.
A right-to-objection request on legitimate-interest processing requires the controller to demonstrate compelling legitimate grounds overriding the data subject interests. Strkr tracks the objection, the basis defense, the decision, and the response. If the objection prevails, processing stops. If the defense prevails, the documentation is audit-ready.
Before fulfilling a DSAR, the controller must verify the requester actually is the data subject. Strkr tracks the verification method (confirmed via a known email, matched against account identifiers, confirmed via secondary contact) and the verification outcome. Requests from unverified parties get a verification challenge, not a full export. The step defends against DSAR-based social engineering.
The GDPR lawful bases map to specific CRM operational patterns. Marketing campaigns to prospective customers typically run under consent (opt-in). Service communications to existing customers typically run under contract. Prospect enrichment typically runs under legitimate interests with a documented balancing test. The CRM has to track which basis applies to which contact for which processing. Here is the pattern.
Marketing consent captures through the webform or preference center. The consent record stores the timestamp, the text agreed to, the source URL, the IP address, and the user agent. Marketing segments filter on consent-granted and consent-not-withdrawn. The campaign cannot send to a contact without active consent on the channel.
Consent is channel-specific. A contact can consent to email marketing while declining SMS and phone. Strkr tracks each channel independently with its own timestamp and source. The marketing module respects the per-channel consent at send time. The preference center lets the subject manage each channel without contacting support.
Service communications to existing customers (account notifications, product updates relevant to the service, billing) run under contract basis. The contact record carries the active contract reference. Service communications bypass marketing consent requirements. Transactional emails about the service are differentiated from marketing emails about new products.
Prospect enrichment, B2B outreach to professional contacts in buying roles, and intra-group transfers often rely on legitimate interests. Strkr tracks the legitimate interest assessment (LIA) as a document linked to the processing activity, with the three-part test (purpose, necessity, balancing) documented. The LIA is audit-ready without a fresh research project.
Public interest processing (public health, scientific research, archiving) applies to specific sectors. Strkr tracks the public-interest basis with the statutory authority referenced on the record. For most commercial CRM operators, this basis does not apply, but for healthcare and research operators it does and the field is available.
Vital interests applies when processing protects a vital interest of the data subject or another person. This is rare in commercial CRM operation (emergency contact scenarios, specific health settings). The basis is available on the record but should be used sparingly with clear documentation.
Legal obligation applies when processing is required by EU or member state law (anti-money-laundering, tax reporting, fraud prevention). The record carries the legal citation. This basis cannot be chosen without identifying the law requiring the processing, so the field validation prompts for the citation.
The post-Schrems II landscape requires every cross-border data transfer to have a documented basis. Standard Contractual Clauses (2021 version), adequacy decisions, specific derogations, or Binding Corporate Rules. The subprocessor chain under Article 28 requires written contracts flowing all the way through. Strkr makes this operational rather than theoretical.
Strkr offers EU-region hosting with primary and backup regions in the European Economic Area. For EU controllers who prefer to keep data in-region, this is the default configuration. The region selection is set at tenant creation and the data lifecycle stays within region. Cross-region access by Strkr support staff is logged and restricted.
The Strkr Data Processing Agreement includes the 2021 Standard Contractual Clauses for data transfers outside the EEA. The controller is Module 1, Strkr is the processor Module 2. The clauses are not optional add-ons; they are default. The DPA is available for e-signature during the subscription setup.
The Strkr subprocessor list is published on the website with the processor name, the processing purpose, the location, and the DPA status. Changes to the list get notified in advance to the subscription contact per the DPA. Controllers can object to new subprocessors per the clauses.
For subprocessors in the US (notably AWS and some integrated AI providers), Strkr maintains the Transfer Impact Assessment documentation per EDPB Recommendations 01/2020. The TIA documents the US surveillance landscape, the subprocessor supplementary measures, and the risk assessment. Controllers can request the TIA under the DPA.
When a Strkr customer connects an integrated vendor (email delivery, calling, enrichment), the vendor is a Strkr subprocessor if the connection runs through Strkr, or a controller-side processor if the connection is customer-managed. Strkr tracks both patterns on the integration record so the controller sees the DPA requirement clearly.
On subscription termination, the Strkr DPA requires the processor to return or delete the controller personal data per the controller instruction, within 30 days unless legal retention applies. The termination export is a one-click archive. The deletion is a documented action with the certificate of destruction available on request.
The DPA includes audit rights under Article 28. Controllers can request documentation of the Strkr GDPR controls (ISMS, incident response, access controls, SOC 2 Type II when complete, HIPAA technical safeguards for health workloads). Specific onsite audits are available on request subject to reasonable notice.
GDPR obligations do not end at consent and DSAR. The storage limitation principle requires retention periods appropriate to the processing purpose. The accountability principle requires documentation. The breach notification obligation requires a 72-hour clock. Each of these runs as a workflow in Strkr, not as a quarterly scramble.
Each record type (Contact, Account, Opportunity, Document, Activity) carries a retention policy configured by the DPO. The policy references the lawful basis and the processing purpose. The nightly retention flow runs the policy, logs the actions, and ships a quarterly retention report. The storage limitation principle runs operationally.
For records where the controller wants to preserve aggregate analytics but not the identifiability, Strkr supports pseudonymization at the end of the active retention period, with full deletion at the end of the archival period. The pseudonymized record keeps non-identifying fields (industry, deal size, won/lost outcome) but strips name, email, phone, and address.
When a record is on legal hold (litigation, regulatory investigation, specific contract retention), the retention policy does not apply. The hold is set with the basis and the expected release date. The record cannot be deleted while the hold is active. When the hold releases, the record returns to the normal retention schedule.
Backups are retained for a documented window (default 30 days, configurable per tenant). An erasure request propagates to backups per the DPA, with the retention time documented. Restorations from backup carry the subsequent re-erasure obligation so that erased records do not resurrect through disaster recovery.
Strkr runs anomaly detection on access patterns (unusual export volumes, atypical geography, after-hours bulk reads, failed-auth spikes). Confirmed incidents surface to the DPO. The 72-hour clock to supervisory authority notification starts on confirmed detection. The incident response playbook is documented and shared with every EU controller customer.
When a breach triggers notification, Strkr drafts the supervisory authority notification letter and the data subject notification letter from the incident evidence. The templates follow the ICO, CNIL, and other common supervisory authority formats. The drafts are reviewed by legal and sent through the controller workflow. The DPO is not building the letter from scratch under time pressure.
The Article 30 Records of Processing Activities inventory is maintained in Strkr Docs with the processing purposes, data categories, data subject categories, recipient categories, transfer basis, and retention periods. The inventory updates as new processing activities get added. The regulator inquiry produces the inventory, not a scramble to assemble it.
A generic CRM may support some GDPR features ad hoc. The Strkr approach is to make each obligation a native workflow. Here is the side-by-side.
| Feature | Strkr | Generic CRM without native GDPR workflows |
|---|---|---|
| Lawful basis as a field | Native field on every contact with the six GDPR bases | Custom field or free text, inconsistent |
| Consent record structure | Timestamp, source, exact text, IP, user agent | Boolean marketing OK field, no granular record |
| Granular channel consent | Email, SMS, phone tracked independently | Single consent flag, no channel granularity |
| DSAR workflow | Native intake, assembly, redaction, response tracking | Email intake, manual assembly, Jira tracking |
| Cross-system erasure | Erasure flow reaches activity, email, backups, warehouse | Main table only, residues remain in related systems |
| Retention automation | Per record type, per lawful basis, nightly flow | Manual or absent, bloat accumulates |
| EU hosting option | Frankfurt or Dublin primary and backup | Varies, often US-primary by default |
| SCCs in DPA | SCCs 2021 included by default | Optional add-on or requires negotiation |
| Subprocessor list | Published and advance-notified changes | Not published or infrequently updated |
| Transfer Impact Assessment | TIA documented for US subprocessors | Often not maintained, controller does the work |
| Breach notification workflow | 72-hour clock, draft letters, submission tracking | Ad hoc, DPO builds the letter from scratch |
| Article 30 records | Live inventory in Docs module | External Word document, often stale |
The actual compliance playbooks across customers in regulated European markets. Each has the trigger, the Strkr feature used, and the measured outcome. The ritual is the compliance.
An EU-based B2B SaaS vendor received 40 to 60 DSARs per quarter from EU and UK data subjects. The team ran the response through email with a 25-day average turnaround. The move to Strkr DSAR workflow dropped the response time to 4 days average with 100 percent on-time delivery. The regulator inquiry a year later produced the full audit trail in 20 minutes.
A German retailer received withdrawal requests through the preference center and through email. The withdrawals used to take 48 hours to propagate from the webform to the marketing tool to the next campaign eligibility. The Strkr workflow brought propagation to under 60 seconds end-to-end. Mis-send rate on withdrawn consent dropped from 2.1 percent to zero.
A French fintech faced a CNIL inquiry on cross-border transfers for the integrated AI note-taker. The TIA documentation was maintained in Strkr through the subprocessor tracking. The response to CNIL was produced in 2 hours and included the full subprocessor chain, the TIA, and the DPA. The inquiry closed without enforcement.
A Nordic healthcare operator had 3 million patient and prospective-patient records with retention policies ranging from 5 to 25 years by record type. Manual retention was unmaintainable. The Strkr retention automation ran nightly, aged out 180,000 records in the first year, and shipped the quarterly compliance report automatically. The DPO cost line dropped by one full-time equivalent.
A Benelux marketing agency detected a confirmed breach from an anomalous export pattern. Strkr surfaced the incident at hour 2, drafted the authority notification by hour 6, legal reviewed by hour 48, and the notification shipped to the Dutch Autoriteit Persoonsgegevens at hour 68. The 72-hour obligation held with 4 hours to spare. Without the workflow, the drafting alone would have consumed the window.
Start a 14-day trial with the full product on from day one. EU hosting, DPA with SCCs 2021, native DSAR workflow, native erasure, native consent management, and native retention automation. Flat per-seat pricing with Marketing, Projects, and Strkr AI included.
Yes. Strkr is GDPR compliant and maintains the operational posture required for an EU-processor relationship: Standard Contractual Clauses 2021 included in the DPA by default, EU-region hosting option in Frankfurt or Dublin, published subprocessor list, maintained Transfer Impact Assessments, native DSAR workflow, native erasure propagation, native consent record structure, native retention automation, and a documented breach notification workflow. The compliance is operational, not just contractual.
EU tenants are hosted in-region with primary and backup facilities in the European Economic Area (Frankfurt and Dublin). The region selection is set at tenant creation and the data lifecycle stays within region. Backups are encrypted and retained for a configurable window. Cross-region access by Strkr support staff is logged, restricted, and governed by the DPA. For non-EU tenants, hosting is in the appropriate region (US-East for US tenants by default, with configurable alternatives).
The DSAR assembly step produces the full data export plus a redaction report that flags fields referencing third-party individuals (notes mentioning other contacts by name, call participants beyond the subject, email threads with other recipients). The privacy coordinator reviews the redaction report before response delivery. The redacted version ships to the subject. The audit trail logs what was redacted and why, so the regulator can audit the redaction decisions if challenged.
The Strkr DPA documents the backup retention window (default 30 days) and the erasure handling. Confirmed erasure requests propagate to the active data stores immediately and are flagged for the backup system. When the current backup rotation window closes (typically within 30 days), the erased records are gone from backups through natural rotation. If a backup must be restored during that window, the restoration process includes the subsequent re-erasure of the relevant records so that the erasure obligation is not undone by disaster recovery.
Yes. The Strkr DPA is available during subscription setup and includes the Article 28 clauses, Standard Contractual Clauses 2021 for transfers outside the EEA, breach notification terms, subprocessor flow-down, controller audit rights, and return/deletion on termination. The DPA is signed before any EU personal data enters the system. For customers in regulated industries, additional specific clauses are available (healthcare BAA for US HIPAA, additional security addenda for financial services).
Marketing consent is granular per channel. A contact can consent to email while declining SMS and phone, or any combination. Each channel carries an independent consent record with timestamp, source, exact text, and withdrawal history. The Strkr Marketing module respects per-channel consent at send time. The preference center lets the data subject manage each channel without contacting support. Consent cannot be bundled across channels, which matches the current CNIL and EDPB guidance.
The TIA follows the EDPB Recommendations 01/2020 structure: identification of the transfer, mapping of applicable third-country laws (FISA 702, Executive Order 12333, US surveillance landscape), assessment of the practical likelihood of access requests, documentation of supplementary measures (encryption, pseudonymization, contractual safeguards, organizational measures), and risk conclusion. The TIA covers Strkr US-based subprocessors (notably AWS for infrastructure in US-hosted regions, and specific AI providers if used). Controllers can request the TIA under the DPA.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
