Evidence for a defined data flow
Forge Data Security and PDPL
Assess Forge using the actual inputs, supplier evidence, privacy roles, processing locations, access, retention and Saudi PDPL requirements relevant to your use case.
A Saudi business evaluating Forge should start with the information it intends to provide, the actions it intends to authorise and the evidence it needs from the supplier. A public privacy policy is a useful starting point. It is not a substitute for understanding the actual data flow or deciding whether that flow meets the organisation's requirements.
Forge's public documents do not establish PDPL certification, Saudi data residency, SOC 2 or ISO certification. Those claims should not be inferred from a local marketing presence or a general security statement. The practical question is whether a defined use case can proceed with appropriate contractual, technical and organisational controls, supported by evidence the responsible reviewers accept.
Classify the inputs before assessing the platform
The Forge platform description centres on knowledge about offers, buyers, problems, proof and marketing context. Much of that knowledge can be prepared from approved public material. A service description is different from a client contract, and an audience category is different from a named contact list.
| Category | Example | Preparation decision |
|---|---|---|
| Approved public business information | Published service scope or product specification | Confirm accuracy, rights and suitability for reuse |
| Confidential business knowledge | Unannounced strategy, internal pricing or a private proposal | Assess necessity, contractual protection and authorised access |
| Personal data | A named testimonial, employee biography or customer email | Identify the purpose, lawful basis, notices and relevant rights process |
| Sensitive or sector-regulated information | Patient information or other restricted records | Keep outside the initial marketing pilot unless specifically assessed and authorised |
| Account and connection information | Administrator identity and social-account authorisation | Review access, credential handling and revocation separately from content |
A file's label does not settle its classification. A “case study” can contain personal or confidential information. A photograph can identify people. Removing a name may still leave a distinctive combination of details. Review the material itself and the purpose for which it would be processed.
Read the published privacy statement precisely
The Forge Privacy Policy, version 1.0 dated 27 July 2026, identifies Trusted Data Technologies Ltd as controller for direct account and business-contact information and says Forge may act as processor for client-submitted personal data, with those activities governed by a Data Processing Addendum.
The policy excludes identifiable personal data, client confidential information and private business configuration from training general-purpose models. It allows aggregated and anonymised information for service improvement. It also describes external service providers, international processing, purpose-based retention and reasonable security measures including access controls, authentication and monitoring.
These statements support specific questions, not broader conclusions. A training exclusion does not identify every model provider or retention period. A reference to security measures does not establish a particular encryption design or independent audit. Request the current contractual and technical evidence needed for your use case, including the referenced processing agreement where relevant.
Map the complete path of the information
Draw a simple data-flow record covering preparation, submission, generation, review, publication and feedback. For each stage, identify the information, purpose, receiving party, location if known and person responsible for approving it. Mark unknowns explicitly rather than filling them with assumptions.
Include material that is easy to overlook: uploaded media, prompts, drafts, support tickets, diagnostic logs and connected-platform responses. A support screenshot can disclose a customer name even when the marketing Node contains no personal data. A publishing connection introduces a separate destination and its own account permissions.
Distinguish processing inside the content workflow from deliberate public disclosure. A draft may be intended for internal review until an authorised person approves publication. Once published to a social platform, its copies and removal process are partly governed by that destination. Deleting source material does not demonstrate that every public copy has been removed.
SDAIA's guide for controllers and processors explains the different roles and the wider regulatory context. It is explanatory guidance, not a replacement for the law and regulations. Use it to organise the questions your privacy team must resolve for the actual activities.
Reduce the information before adding controls
Ask whether the marketing task can be completed with less information. A public service outline, a permitted sample and aggregate buyer questions may supply sufficient context. A complete CRM export or client archive should not be the default route to a better description.
Article 19 of the PDPL Implementing Regulation addresses collecting and processing the minimum personal data needed for the purpose. Apply that principle to each proposed input. Keep the explanation of why a field is needed with the data-flow record.
Illustrative example: an archival digitisation supplier wants to explain its project-scoping service. It has an approved brochure, a blank workflow diagram and raw client archive samples containing names and signatures. The initial marketing brief can use the brochure and blank diagram. The client records do not become necessary merely because they would make the example more detailed.
If the team wants to publish a real case, it should establish the permitted public facts and review the risk of re-identification before preparing the source. Keep confidential background out of generation inputs when the approved lesson can be expressed without it. Label an invented example as illustrative instead of manufacturing a client narrative.
Turn security questions into evidence requests
Ask for information that lets the reviewer make a decision. “Is it secure?” is too broad. A useful request states the proposed data and action, then asks for the relevant control and supporting evidence. The depth should match the use case rather than becoming an indiscriminate questionnaire.
| Area | Decision question | Evidence to review |
|---|---|---|
| Access | Who can administer, view, generate and publish? | Current account controls, support-access process and revocation demonstration |
| Protection | How is the proposed information protected in transit and storage? | Technical description and any applicable independent assurance |
| Providers | Which organisations receive which categories of information? | Current provider or subprocessor information and change-notification terms |
| Retention | How long do source data, drafts, logs and backups remain? | Category-specific periods, deletion process and exceptions |
| Incidents | How will the customer be informed and supported? | Contractual notification process, contacts and response responsibilities |
| Exit | What can be exported, revoked and deleted when use ends? | Demonstrated export and closure procedure with documented limits |
If an assurance report or certificate is offered, inspect its entity, service scope, date and limitations. A certificate for a cloud provider does not automatically certify every application using that provider. If a required control is not available, decide whether a narrower input set or operating restriction adequately addresses the need; do not describe an unanswered question as a verified capability.
Assess location and transfers from the actual provider chain
Ask where application data, backups, logs and AI processing occur, and whether support personnel access them from other locations. A hosting-region answer that excludes model processing or onward providers may leave the important question unresolved. Obtain the information at the level needed to assess the proposed flow.
Saudi Arabia's Regulation on Personal Data Transfer Outside the Kingdom addresses transfer conditions, safeguards, onward transfers and risk assessment. The responsible privacy or legal team should assess the applicable route and evidence. Do not assume either that PDPL universally requires all information to stay in Saudi Arabia or that an overseas location is acceptable without the required assessment.
Sector rules and customer commitments may add constraints. Identify those obligations for the actual entity and activity before deciding that a general supplier statement is sufficient. A low-risk public-content pilot and a proposed workflow involving regulated personal records may require materially different decisions.
Preserve purpose, rights and retention through connected workflows
Decide who handles correction, deletion, access requests and consent changes where personal data is involved. The business should know how to find the relevant record and which other systems received it. Document the limits of deletion, including legal retention exceptions and the handling of backups, with the appropriate reviewers.
If CRM feedback is introduced, define the minimal information that returns to editorial planning. The CRM handoff guide provides a proposed design without assuming a native connector. A useful theme such as “buyers misunderstand the implementation scope” may not require names, message transcripts or opportunity values.
Direct marketing introduces a separate purpose and recipient controls. Article 29 of the Implementing Regulation addresses consent, sender identity and stopping direct-marketing communications. Publishing general content and sending personal outreach should not be treated as the same data flow. The email workflow guide explains the operational handoff.
Run a limited pilot with explicit acceptance conditions
Begin with approved public business material, synthetic examples where useful and the minimum authorised channel access. Record who may provide source material, who checks it and who approves publication. Keep confidential or regulated records outside that first scope unless the separate assessment has been completed.
Test practical controls: the intended account connects, the correct destination is selected, publication requires the agreed review, access can be revoked through the available process and a correction can be handled. These are workflow checks. They do not replace a security audit or prove that every legal obligation is met.
At the decision point, distinguish three outcomes: proceed within the assessed scope, proceed after specified evidence or controls are completed, or do not use the proposed data flow. Record the unresolved requirement and its owner. A conditional decision is useful only when the condition is concrete and can be verified.
The content governance workflow helps maintain source and publication controls after procurement. Revisit the assessment when the data, provider arrangement, connected systems or use case changes materially.
Request a Forge demo with your security and data-flow requirements. Bring a non-sensitive description of the intended inputs and actions, plus the evidence your reviewers need. Evaluate the defined workflow and its limits before expanding the information the team submits.