{"id":3822,"date":"2026-10-20T11:31:45","date_gmt":"2026-10-20T11:31:45","guid":{"rendered":"https:\/\/sawaryn.com\/?p=3822"},"modified":"2026-10-20T11:41:46","modified_gmt":"2026-10-20T11:41:46","slug":"sharing-employee-data-corporate-group-dpa","status":"publish","type":"post","link":"https:\/\/sawaryn.com\/en\/publikacje\/sharing-employee-data-corporate-group-dpa\/","title":{"rendered":"Sharing Employee Data Within a Corporate Group: When a DPA Is Not Enough"},"content":{"rendered":"

If your company operates within a corporate group, sooner or later someone will make a request along the lines of: \u201cadd us to the system, we already have a DPA”. It sounds reasonable. But in most cases, it is not true. If the parent company accesses the data to calculate its own margins, control costs or oversee remuneration, it is not acting on your instructions. It is acting as a separate controller. And that means an entirely different document, a different legal basis and a different scope of data.<\/p>\n

Incorrect classification of roles \u2014 controller, processor, joint controller \u2014 is one of the most common recurring errors in GDPR documentation within corporate groups. Decisions by the President of the Personal Data Protection Office (PUODO) document repeated infringements of Article 28 GDPR: no written data processing agreement, incomplete specification of data categories, and documentation being put in place only after an incident<\/a> (UODO \u2014 several GDPR infringements result in a fine<\/a>).<\/p>\n

In this article, I will show you how to use one question \u2014 \u201cwhose purpose is it?” \u2014 to classify roles correctly. We will cover how to choose the right instrument (a DPA or a data-sharing agreement), narrow the scope of data, comply with transparency obligations, define retention periods and configure tools. No theory \u2014 just specific steps you can implement.<\/p>\n

Key concepts before you begin<\/h2>\n

Before we move on to the details, it is worth clarifying three concepts that determine which document you need to prepare.<\/p>\n\n\n\n\n\n\n\n
Concept<\/th>\nWhat it means<\/th>\nWhen it applies<\/th>\n<\/tr>\n<\/thead>\n
Controller<\/strong> (Article 4(7) GDPR)<\/td>\nAn entity that independently determines the purposes and means of processing personal data<\/td>\nThe parent company analyses remuneration data for its own controlling purposes<\/td>\n<\/tr>\n
Processor<\/strong> (Article 4(8) GDPR)<\/td>\nAn entity that processes data solely on the controller\u2019s instructions<\/td>\nAn external IT provider operates an HR system on behalf of the company<\/td>\n<\/tr>\n
Joint controller<\/strong> (Article 26(1) GDPR)<\/td>\nTwo or more entities that jointly determine the purposes and means of processing<\/td>\nTwo companies jointly conduct a recruitment process and decide together how it will operate<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Each of these concepts is functional in nature<\/strong> \u2014 it is determined by what the entities actually do with the data, not by the title of the agreement they have signed. In its decisions, UODO refers to EDPB Guidelines 07\/2020, confirming that an entity does not even need to have physical access to data to be its controller (UODO \u2014 Which entity should be regarded as the controller<\/a>).<\/p>\n

DPA<\/strong> (Data Processing Agreement) \u2014 a data processing agreement<\/a> under Article 28 GDPR. It governs only situations in which a processor processes data on the controller\u2019s instructions.<\/p>\n

Data-sharing agreement<\/strong> \u2014 a document governing the transfer of data between two separate controllers, each of which processes it for its own purposes.<\/p>\n

The one question that determines which document to use<\/h2>\n

Before granting anyone access to another group company\u2019s system, answer one question: \u201cwhose purpose is it?”<\/strong><\/p>\n

The answer determines everything:<\/p>\n\n\n\n\n\n\n\n
Answer<\/th>\nRecipient\u2019s role<\/th>\nRequired document<\/th>\n<\/tr>\n<\/thead>\n
The recipient accesses the data on the instructions of<\/strong> the system controller, pursuing that controller\u2019s purpose<\/td>\nProcessor<\/td>\nData Processing Agreement (DPA) under Article 28 GDPR<\/td>\n<\/tr>\n
The recipient accesses the data for its own purposes<\/strong> (oversight, controlling, settlements)<\/td>\nSeparate controller<\/td>\nController-to-controller data-sharing agreement<\/td>\n<\/tr>\n
Both entities jointly determine<\/strong> the purposes and means of processing<\/td>\nJoint controllers<\/td>\nArrangement under Article 26 GDPR<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Shareholder oversight, margin control, cost allocation and verification of employment terms are the purposes of the parent company. They are not the purposes of the company that operates the system. A DPA governs only processing carried out on instructions. If the parent company reviews data for its own purposes, a DPA is the wrong instrument, regardless of how broadly it is drafted.<\/p>\n

The CJEU judgment in the Fashion ID case (C-40\/17, 29 July 2019) confirms that joint controllership may cover only a distinct stage of the processing chain and does not extend to operations whose purposes or means an entity does not actually determine (EUR-Lex \u2014 CJEU judgment C-40\/17<\/a>). Mere membership of the same corporate group, use of a common brand or technical use of the same system does not automatically create joint controllership.<\/p>\n

Why an existing DPA is usually not enough<\/h3>\n

A typical \u201cmutual” DPA within a corporate group describes the scope of data as \u201ccontact and basic details of the parties\u2019 personnel and customers”. Meanwhile, a recruitment and records management system contains:<\/p>\n

    \n
  1. Candidates\u2019 CVs (often including special category data under Article 9 GDPR)<\/li>\n
  2. Hourly rates and availability information<\/li>\n
  3. Subcontracting data<\/li>\n
  4. LinkedIn profiles and activity history<\/li>\n<\/ol>\n

    This scope goes far beyond the literal wording of a standard DPA. Retrieve the DPA currently in force and compare its description of data categories with what is actually visible in the system. If the agreement refers to \u201ccontact details” while the system contains CVs and rates, the agreement does not cover them.<\/p>\n

    Risks of incorrectly classifying roles within a corporate group<\/h2>\n

    Incorrectly classifying a recipient as a processor rather than a separate controller may trigger several GDPR infringements at the same time. An infringement of Article 6(1) GDPR is subject to Article 83(5)(a) GDPR \u2014 the maximum fine is up to EUR 20,000,000<\/strong> or up to 4% of total worldwide annual turnover<\/strong> (GDPR \u2014 Article 83<\/a>).<\/p>\n

    a) Legal risk: no legal basis<\/h3>\n

    If the parent company obtains access to data under a DPA but actually processes it for its own purposes, there is no appropriate legal basis under Article 6(1) GDPR. PUODO has imposed both reprimands and substantial financial penalties for such infringements. In 2025, PUODO fined Poczta Polska PLN 27 million for processing without a legal basis (UODO \u2014 notice on penalties<\/a>).<\/p>\n

    b) Operational risk: excessive access<\/h3>\n

    Granting access to the entire system view \u2014 including CVs and the candidate database \u2014 \u201cfor organisational convenience” violates the data minimisation principle (Article 5(1)(c) GDPR). The company needs three pieces of information: who, for which client and at what rate. Instead, it receives the candidate\u2019s entire profile, including their address, bank account number and employment history.<\/p>\n

    c) Retention risk<\/h3>\n

    Including \u201cpermanent access \/ until revoked” in the agreement may refer to the term of the arrangement. But the retention period for reports<\/strong> cannot be indefinite \u2014 Article 5(1)(e) GDPR requires data to be kept no longer than necessary for the purposes of processing (GDPR \u2014 Article 5<\/a>).<\/p>\n

    d) Reputational and organisational risk<\/h3>\n

    A discrepancy between the Privacy Statement and what the system actually allows may prompt complaints from employees and consultants. If you have told people that only Company A can see their data while Company B can actually see it too, you have a transparency problem.<\/p>\n\n\n\n\n\n\n\n\n\n
    Type of risk<\/th>\nSource<\/th>\nPossible consequence<\/th>\n<\/tr>\n<\/thead>\n
    No legal basis<\/td>\nIncorrect role classification<\/td>\nFine of up to EUR 20 million \/ 4% of turnover<\/td>\n<\/tr>\n
    Breach of data minimisation<\/td>\nExcessive scope of data<\/td>\nOrder to restrict processing<\/td>\n<\/tr>\n
    Indefinite retention<\/td>\nNo defined retention period<\/td>\nChallenge by the supervisory authority or data subject<\/td>\n<\/tr>\n
    Inconsistent information<\/td>\nDiscrepancy between the privacy notice and actual practice<\/td>\nComplaints, PUODO proceedings<\/td>\n<\/tr>\n
    Business delay<\/td>\nDisorganised documentation<\/td>\nMargin and cost monitoring blocked<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Contact us<\/a><\/p>\n

    How to share data correctly within a corporate group \u2014 step by step<\/h2>\n

    Step 1: determine each party\u2019s role for each process<\/h3>\n

    One DPA \u201cfor everything” is not enough. For each processing activity, you must determine separately:<\/p>\n

      \n
    1. Who determined the purpose of the processing<\/li>\n
    2. Whether the decision on the purpose was made jointly<\/li>\n
    3. Who decides on the essential means of processing<\/li>\n
    4. Whether one company acts solely on the instructions of the other<\/li>\n<\/ol>\n

      Training the people who grant access (IT, HR, administrators) to use the simple \u201cwhose purpose is it?” test eliminates most incorrectly executed DPAs within a group.<\/p>\n

      Step 2: choose the right instrument<\/h3>\n

      Based on the answers from step 1:<\/p>\n\n\n\n\n\n\n\n
      Situation<\/th>\nInstrument<\/th>\n<\/tr>\n<\/thead>\n
      Company A operates the system and Company B accesses the data on A\u2019s instructions<\/td>\nDPA (Article 28 GDPR) \u2014 update the existing one<\/td>\n<\/tr>\n
      Company B accesses the data for its own purposes (controlling, oversight)<\/td>\nController-to-controller data-sharing agreement<\/td>\n<\/tr>\n
      Both companies jointly decide on the purposes and means<\/td>\nJoint controller arrangement (Article 26 GDPR)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Step 3: limit the scope of data to the minimum<\/h3>\n

      Instead of sending full employment contracts, request a report for each individual. A full employment contract contains remuneration, a bank account number, an address and often special category data (Article 9 GDPR). Sending it in full violates the data minimisation principle.<\/p>\n

      What the report should contain:<\/strong><\/p>\n

        \n
      1. Position<\/li>\n
      2. Remuneration (amount)<\/li>\n
      3. Start and end date<\/li>\n
      4. Hourly rate (if applicable)<\/li>\n
      5. Monthly amount<\/li>\n<\/ol>\n

        What to remove:<\/strong><\/p>\n

          \n
        1. Bank account number<\/li>\n
        2. Home address<\/li>\n
        3. Data that may constitute special category data<\/li>\n
        4. CV (a source of Article 9 data \u2014 a separate process if there is a distinct purpose)<\/li>\n<\/ol>\n

          Check with IT whether the report actually extracts from the system the fields you listed in the data scope appendix. In the cases described, several fields needed to calculate margins were not included in the list of fields provided by the system controller.<\/p>\n

          Step 4: conduct a Legitimate Interests Assessment (LIA)<\/h3>\n

          The legal basis for sharing data for shareholder oversight<\/a> may be a legitimate interest<\/strong> (Article 6(1)(f) GDPR). Recital 48 GDPR indicates that undertakings belonging to a group may have a legitimate interest in transmitting personal data within the group for internal administrative purposes (GDPR \u2014 Recitals 47\u201348<\/a>). However, Recital 48 is an interpretive guideline, not a standalone legal basis.<\/p>\n

          For each process, conduct a three-stage assessment:<\/p>\n\n\n\n\n\n\n\n
          Stage<\/th>\nQuestion<\/th>\nExample<\/th>\n<\/tr>\n<\/thead>\n
          1. Interest<\/td>\nIs the interest specific and genuine?<\/td>\nMonitoring margins and employment costs at a subsidiary<\/td>\n<\/tr>\n
          2. Necessity<\/td>\nIs the processing necessary? Are there alternatives?<\/td>\nA report containing 5 fields instead of full access to the system<\/td>\n<\/tr>\n
          3. Balancing<\/td>\nIs the interest overridden by the rights of individuals?<\/td>\nNarrow scope of data, limited group of recipients, technical safeguards<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          The broader the scope of the data shared, the higher the required threshold for the legal basis. Data sharing based on Article 6(1)(f) is defensible precisely because of its narrow scope. Data minimisation is not an obstacle \u2014 it is an argument that will help justify the data sharing before the supervisory authority.<\/p>\n

          Note: no published position has been identified from PUODO or the EDPB that directly addresses the transfer of named remuneration data concerning a subsidiary\u2019s employees to its parent company. UODO states that shareholder oversight is not the same as control over processing within the meaning of the GDPR and does not automatically grant access to employee data (UODO \u2014 Data protection in the workplace<\/a>). The permissibility of such a transfer must be assessed on a case-by-case basis.<\/p>\n

          Step 5: comply with transparency obligations before launch<\/h3>\n

          The following conditions must be met before data sharing begins:<\/p>\n

            \n
          1. Provide a privacy notice<\/a> to the consultants and employees whose data will be seen by the new recipient<\/li>\n
          2. Update the disclosing party\u2019s Privacy Statement so that it reflects how the system actually operates<\/li>\n
          3. Verify that the system\u2019s functionality is consistent with what you communicate to individuals<\/li>\n<\/ol>\n

            Article 14(1) GDPR applies where data has not been obtained directly from the individual. The new controller should provide its own privacy notice covering, among other things, the controller\u2019s identity, purpose, legal basis, data categories, source, recipients, retention period and the individual\u2019s rights. The deadline is generally one month after obtaining the data (GDPR \u2014 Article 14<\/a>).<\/p>\n

            A privacy notice provided to an individual by the first entity does not replace the second controller\u2019s transparency obligations.<\/p>\n

            Step 6: define the report retention period<\/h3>\n

            Article 74 of the Polish Accounting Act distinguishes between different retention periods: approved annual financial statements \u2014 permanently; accounting books and accounting records \u2014 generally for 5 years (Accounting Act \u2014 Journal of Laws 2023, item 120<\/a>).<\/p>\n

            However, \u201cshareholder reports” and \u201ccontrolling reports” are not categories defined in the Accounting Act. A five-year period is defensible only for documents that form part of accounting books or accounting records.<\/p>\n\n\n\n\n\n\n\n\n
            Document category<\/th>\nRetention period<\/th>\nLegal basis<\/th>\n<\/tr>\n<\/thead>\n
            Approved annual financial statements<\/td>\nPermanently<\/td>\nArticle 74 of the Accounting Act<\/td>\n<\/tr>\n
            Accounting books, accounting records<\/td>\n5 years<\/td>\nArticle 74 of the Accounting Act<\/td>\n<\/tr>\n
            Management \/ controlling reports<\/td>\nTo be determined \u2014 e.g. current financial year + settlement period<\/td>\nArticle 5(1)(e) GDPR<\/td>\n<\/tr>\n
            Working copies, dashboards<\/td>\nDelete after use<\/td>\nData minimisation principle<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

            Specify a concrete period in the agreement. \u201cPermanent access \/ until revoked” may refer to the term of the arrangement, but not to data retention.<\/p>\n

            Step 7: configure the report-sharing tool<\/h3>\n

            Compliance with Article 32 GDPR does not result from the choice of tool \u2014 it depends on how the tool is configured. SharePoint is not inherently compliant or non-compliant (UODO \u2014 data security, Article 32<\/a>).<\/p>\n

            Report repository configuration checklist:<\/strong><\/p>\n

              \n
            1. Dedicated library \u2014 not a folder in the general structure<\/li>\n
            2. No inheritance of permissions from the organisation<\/li>\n
            3. Disable \u201canyone with the link” links<\/li>\n
            4. Permissions assigned by role, not by organisation<\/li>\n
            5. TLS encryption in transit and encryption at rest<\/li>\n
            6. Audit log enabled and retained<\/li>\n
            7. Closed and documented group of recipients<\/li>\n
            8. Retention rule for the library consistent with the period specified in the agreement<\/li>\n<\/ol>\n

              Confirm the hosting location of the system and repository. The absence of transfers outside the EEA is something to be confirmed<\/strong>, not assumed by default. If anything is located outside the EEA, this is a separate issue requiring a separate transfer mechanism<\/a> (Article 46 GDPR).<\/p>\n

              Step 8: issue authorisations and confidentiality undertakings<\/h3>\n

              Before granting access:<\/p>\n

                \n
              1. Issue individual data processing authorisations to every person with access<\/li>\n
              2. Obtain confidentiality undertakings<\/a><\/li>\n
              3. Limit the group of recipients to the minimum \u2014 with an answer to the question \u201cwho exactly and for what purpose”<\/li>\n
              4. Document the controller\u2019s instructions or appendix<\/li>\n<\/ol>\n

                An authorisation defines the scope and purpose, is documented and may be withdrawn if responsibilities change or the relationship ends.<\/p>\n

                When BCRs will not replace a separate agreement<\/h2>\n

                Corporate groups are often tempted to think: \u201cwe have BCRs \/ an intra-group agreement, so that covers all access”. It does not.<\/p>\n

                BCRs<\/strong> (Article 46(2)(b) and Article 47 GDPR) are a transfer instrument \u2014 they are used to transfer data to third countries within a group and require approval from a supervisory authority (UODO \u2014 binding corporate rules<\/a>). BCRs do not replace a Data Processing Agreement (Article 28) or a joint controller arrangement (Article 26).<\/p>\n

                BCRs are not required for relationships located entirely within the EEA. The appropriate instrument is a Data Processing Agreement or a data-sharing agreement, depending on how the roles are classified.<\/p>\n

                A document merely called an \u201cintra-group agreement” is not a set of BCRs if it does not meet the requirements of Article 47 and has not been approved by a supervisory authority.<\/p>\n

                An additional formality that is easy to overlook: if the framework agreement and DPA were signed using outdated entity names following a name change or restructuring, verify the details using extracts from the relevant register and sign an amendment confirming continuity.<\/p>\n

                We can help you<\/h2>\n

                Putting roles and documentation within a corporate group in order is not a one-off amendment to an agreement. It requires a review covering the classification of roles for each process, comparison of existing DPAs with the actual scope of data in systems, preparation of the appropriate instrument and updates to privacy notices.<\/p>\n

                We support companies within corporate groups \u2014 especially Polish entities with foreign owners \u2014 through three service options:<\/p>\n\n\n\n\n\n\n\n
                Option<\/th>\nScope<\/th>\nWho it is for<\/th>\n<\/tr>\n<\/thead>\n
                Role classification audit<\/strong><\/td>\nReview of existing DPAs and access maps<\/a>, identification of gaps<\/td>\nCompanies that want to understand their current position<\/td>\n<\/tr>\n
                Agreement + privacy notices<\/strong><\/td>\nPreparation of a data-sharing agreement, updated privacy notices and a data scope appendix<\/td>\nCompanies that need a specific document<\/td>\n<\/tr>\n
                Comprehensive solution<\/strong><\/td>\nAudit + agreement + tool configuration checklist (Article 32) + retention policy + training for people who grant access<\/td>\nCompanies that want to address the issue from start to finish<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                We combine GDPR compliance with business context \u2014 we understand that the finance department needs data to calculate margins, not to read CVs. We design documentation to enable access, not block it.<\/p>\n

                Contact us<\/a><\/p>\n

                Data sharing within a corporate group \u2014 key takeaways<\/h2>\n

                Before adding anyone to a group system, answer the question \u201cwhose purpose is it”. The answer determines which document to use: a DPA, a data-sharing agreement or a joint controller arrangement.<\/p>\n

                Limit the scope of data to the minimum \u2014 use a report for each individual instead of full employment contracts. Define a report retention period. Update the privacy notice before data sharing begins. Configure the tool in accordance with the Article 32 checklist.<\/p>\n

                Data minimisation does not prevent shareholder oversight. On the contrary \u2014 it gives the data sharing a stronger legal basis.<\/p>\n

                If you need a review of intra-group agreements, an access map or assistance in preparing a data-sharing agreement, contact us<\/a>.<\/p>\n

                Frequently asked questions<\/h2>\n

                We have signed a DPA covering the entire group \u2014 doesn\u2019t that cover all access to our systems?<\/strong><\/p>\n

                No. A DPA (a Data Processing Agreement under Article 28 GDPR) governs only situations in which a processor processes data on the controller\u2019s instructions. If a group company accesses a system for its own purposes \u2014 oversight, controlling or cost allocation \u2014 it acts as a separate controller. A data-sharing agreement is required, not a DPA. You should also check whether the literal description of data categories in the DPA covers what is actually visible in the system.<\/p>\n

                As the majority shareholder, I have the right to know how much we pay people at the subsidiary. Why does the GDPR complicate this?<\/strong><\/p>\n

                The GDPR does not prohibit access to this information \u2014 it requires the scope of access to be proportionate to the purpose. A full employment contract includes remuneration, but also a bank account number, an address and potentially special category data. Instead of sending complete agreements, prepare a report for each individual containing their position, remuneration, dates and rate. This is sufficient for oversight while also complying with the data minimisation principle. No PUODO position has been identified that explicitly permits or prohibits the transfer of named remuneration data to a parent company \u2014 each case requires an individual assessment.<\/p>\n

                Can I state in the agreement that access is \u201cpermanent \/ until revoked”?<\/strong><\/p>\n

                Such a provision may refer to the term of the arrangement (e.g. for as long as the ownership relationship continues). However, the retention period for reports<\/strong> must be specified precisely \u2014 Article 5(1)(e) GDPR does not permit indefinite retention of personal data. Consider using the following formula: the current financial year plus the settlement period. Documents forming part of the accounting books may be retained for 5 years under Article 74 of the Accounting Act.<\/p>\n

                Is SharePoint sufficient for exchanging reports containing remuneration data?<\/strong><\/p>\n

                It may be \u2014 but compliance with Article 32 GDPR does not result from the choice of tool; it depends on how it is configured. You need a dedicated library with no permission inheritance, no \u201canyone with the link” links, role-based permissions, an enabled audit log and a retention rule consistent with the agreement. You should also confirm where the repository is hosted \u2014 if it is outside the EEA, this is a separate issue requiring a transfer mechanism.<\/p>\n

                The parent company is based in another EU country \u2014 is that a data transfer?<\/strong><\/p>\n

                If both companies and the systems are located within the EEA, there is no transfer of data to a third country and you do not need any additional mechanisms under Chapter V GDPR. However, this must be confirmed: check where the system and report repository are hosted. The location of the server, not the company\u2019s registered office, determines whether a transfer takes place.<\/p>\n

                Who should implement this within the company: Legal, HR or IT?<\/strong><\/p>\n

                All three. Legal classifies the roles and prepares the documents. HR updates the privacy notices and provides them to employees and consultants. IT configures system permissions, prepares the report with the correct fields and implements retention rules. Without cooperation between these three departments, the documentation will not be consistent with what actually happens in the system \u2014 and that consistency is precisely what the supervisory authority checks.<\/p>\n","protected":false},"excerpt":{"rendered":"

                Learn when intra-group access requires a DPA or data-sharing agreement, and how to limit employee data, set retention periods and configure access.<\/p>\n","protected":false},"author":13,"featured_media":3826,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"","sip_alt_url":"","sip_en_pl_url":"","sip_pair_uuid":"f9a5ebc0-6dfa-4874-9d43-fd353146aef8","sip_pair_state":"verified"},"categories":[1584],"tags":[1555,1446,1553,1531,1546,1534],"specialization":[1214],"practice_area":[],"class_list":["post-3822","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-contract-law","tag-corporate-governance-en","tag-gdpr","tag-gdpr-audit","tag-personal-data-protection","tag-risk-assessment","tag-uodo-en","specialization-contract-law"],"acf":[],"_links":{"self":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/posts\/3822","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/comments?post=3822"}],"version-history":[{"count":5,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/posts\/3822\/revisions"}],"predecessor-version":[{"id":3831,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/posts\/3822\/revisions\/3831"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/media\/3826"}],"wp:attachment":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/media?parent=3822"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/categories?post=3822"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/tags?post=3822"},{"taxonomy":"specialization","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/specialization?post=3822"},{"taxonomy":"practice_area","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/practice_area?post=3822"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}