Clarification Needed: Storing PII Data in AEM as a Cloud Service (Security, Compliance & Encryption)

Hello ​@RanjithR1, storage of PII data comes with a catch - the company that is storing the data might/will need a data protection license and should adhere to the local jurisdiction policies. So please check if this is applicable to your employer. Also, one good rule is, having no PII data is better than having PII data.

Usually customer data is not saved in AEM (not recommended as well) and it is better to choose 3rd party storage for the same. You can choose any cloud database (like DynamoDB) or any CRM system (like Hubspot) as they can support more customer oriented outputs (like lead generation, unique visitors etc).

While storing in 3rd party systems, you can follow the encryption process and standard safety measures. When AEM is dealing with content traffic and requests, the 3rd party system can deal with the CRUD operations of PII data. In this way, it would be decoupled and easy to maintain. Please check your business need and choose the right option.

Hope this helps!

Regards,

Ramkumar

Hi ​@RanjithR1 

For AEM as a Cloud Service, the secure capability is there, but the architecture recommendation is:

• Use AEM as experience/presentation layer, and keep PII in a dedicated, secured backend wherever possible.

1. Should we store PII in AEMaaCS at all?

• Technically possible and protected, but not preferred as a system of record.
• For Sites specifically, Adobe explicitly notes that form data should normally be sent to back‑end systems rather than stored on publish:
  • "By default AEM Sites components do not store form-data entered by visitors on the publish server. It is recommended to forward the data to a third-party system…"
    • https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/compliance/data-privacy/sites-readiness
  • For Forms, Adobe goes further: in production it is recommended not to store draft or submitted form data in AEM repository, but in a secure external store (database, etc.).
    • https://experienceleague.adobe.com/en/docs/experience-manager-65/content/forms/publish-process-aem-forms/configuring-draft-submission-storage
• So: only store the minimum PII you truly need for AEM functionality (e.g., user profiles, consents, limited UGC).

2. How does AEMaaCS protect data?

• In transit: TLS for all endpoints.
• At rest: data in AEMaaCS is encrypted at rest and hosted on hardened, monitored cloud infrastructure. https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/security/cloud-service-security-overview
• External threats: built‑in CDN, traffic filter & optional WAF rules for DoS/DDoS and malicious traffic, regular security patching.https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/security/traffic-filter-and-waf-rules/overview
• Privacy/compliance responsibilities (GDPR/CCPA, etc.) remain with the customer, with Adobe providing the platform and tooling.  https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/compliance/data-privacy/aem-readiness

3. PII in JCR – guidelines

If you must keep some PII in JCR:

• Data minimization: avoid sensitive categories (health, PCI, etc.) and store only what is required.
• Strict ACLs: lock down paths containing user profiles or PII; no "everyone" or anonymous read.
• Retention & deletion: implement processes (APIs/scripts) to find and delete per privacy requests as described in the privacy readiness docs. https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/compliance/data-privacy/foundation-readiness

4. Custom encryption (OSGi) – is it OK?

Yes, you can encrypt data before writing it to JCR (e.g., via an OSGi service), but:

• You must manage keys securely (e.g., external KMS, environment secrets).
• You still own privacy/compliance; encryption is defense‑in‑depth, not a substitute for minimization or proper architecture.

For Forms in Cloud Service, Adobe's recommended pattern is externalization of workflow and submission data to Azure Blob/other storage, not keeping clear PII in JCR at all.

https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/forms/create-aem-workflow/externalize-workflow

https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/forms/forms-cs-azure-portal/introduction

5. Recommended architectural pattern

For a "clean" answer to your architects/compliance:

Preferred:

• AEMaaCS holds content + minimal profile/consent data.
• All rich PII (accounts, addresses, IDs, financial/health data, etc.) lives in a secure backend (CRM, core system, IdP, or dedicated data service), integrated via APIs/Data Models.

When using AEM Forms CS: use the out‑of‑the‑box connectors (Azure, DB) and store submissions and workflow payloads externally instead of JCR.

That gives you the strongest story: AEMaaCS remains a highly secure experience layer, while your regulated PII stays in systems purpose‑built and governed as systems of record.

Hi ​@RanjithR1 

do not store PII in AEM. It’s a phenomenal content management system, but it is not a CRM, a CDP, or a secure data vault.

While it's true that AEMaaCS encrypts data at rest and in transit, and is heavily protected from external threats by Fastly and Adobe's WAF, storing sensitive user data in the JCR is an architectural anti-pattern. It creates massive GDPR and CCPA compliance headaches, mostly because internal authors or admins could accidentally gain access to it.

The Right Way (Pass-Through Architecture) Use AEM to render the beautiful front-end forms, but don't save the data in AEM. When a user hits submit, either:

1. Make an AJAX call straight from the browser to your secure backend API.

2. Have the form submit to an AEM Servlet, which acts as a proxy to instantly forward that payload to your backend system (like Salesforce or AWS) without ever calling session.save().

If You Are Absolutely Forced to Store it in AEM If it's a hard requirement (like a temporary retry queue), you have to lock it down. I would write an OSGi service using AEM’s built-in CryptoSupport API to encrypt the data before saving it. Then, store it in a highly restricted folder like /var/secure-forms (never under /content), and set up aggressive ACLs so only a specific system user can read it.

Let AEM do what it does best managing content. Let your backend systems handle the sensitive data!.

Thanks
Partyush. 

Hey ​@RanjithR1 

This is a great set of questions around PII handling in AEM as a Cloud Service. Here's a  breakdown:

Is it recommended to store PII in AEMaaCS?

Generally, no. AEM is a content management system, not a system of record for sensitive personal data. Adobe's own guidance discourages storing PII directly in the JCR repository. AEM is optimized for content delivery, not secure data vaulting.

How Adobe protects data at rest and in transit

• In transit: All communication uses TLS 1.2+ encryption (HTTPS)

• At rest: Adobe manages encryption of the underlying storage infrastructure (Azure Blob Storage / cloud-tier storage), but this is infrastructure-level encryption — not field-level or application-level encryption of individual JCR properties

• Access control: AEM provides ACL-based permissions on repository nodes, but these are authorization controls, not data protection mechanisms in the compliance sense

PII in JCR repositories

Adobe does not provide built-in field-level encryption for JCR properties. The repository is designed for content, not sensitive data. Key concerns:

• JCR content can appear in packages, backups, replication queues, and logs

• Dispatcher caching could inadvertently expose data

• AEM's search indexes (Oak Lucene/Elastic) may index PII fields

• No built-in data retention/purging lifecycle for PII compliance (GDPR right to erasure, etc.)

Protection from external threats

AEMaaCS includes:

• Adobe-managed WAF and DDoS protection via the CDN layer

• Network isolation of author/publish tiers

• Regular security patching (managed by Adobe)

• But these protect the platform, not necessarily your data model choices

Custom encryption via OSGi service

Yes, technically possible — you could write an OSGi service that encrypts/decrypts values before storing them in the JCR:

@Component(service = EncryptionService.class)
public class EncryptionService {
    public String encrypt(String plaintext) throws Exception {
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
// use a key from a secure source (e.g., Adobe Cloud Manager secret env vars)
        cipher.init(Cipher.ENCRYPT_MODE, getKey(), new GCMParameterSpec(128, generateIv()));
        return Base64.getEncoder().encodeToString(cipher.doFinal(plaintext.getBytes(UTF_8)));
    }
}

However, this approach has significant drawbacks:

• Key management becomes your responsibility (rotation, storage, access)

• Encrypted values break search, indexing, and query capabilities

• Doesn't address PII leaking into logs, packages, or replication queues

• Adds complexity without solving the fundamental architectural mismatch

The strongly recommended approach is to store PII in a purpose-built secure backend and reference it from AEM:

1. Store PII externally — Use a system designed for sensitive data: a database behind an API layer (e.g., a microservice on AWS with RDS/DynamoDB + KMS encryption), a CRM like Salesforce, or Adobe Experience Platform with proper data governance

2. Reference by ID in AEM — Store only an opaque, non-reversible identifier in the JCR that maps to the external record

3. Fetch at runtime — Use Sling Models or servlets to retrieve PII from the secure backend on demand, over authenticated API calls

4. Use Adobe I/O Runtime / App Builder — For server-side processing that needs PII, keep it outside AEM's content tier entirely

5. Forms-specific: If using AEM Forms, leverage the Forms Data Model to submit directly to a secure backend without persisting PII in the JCR

The right pattern is to treat AEM as the presentation layer and keep PII in systems with proper encryption, access auditing, retention policies, and compliance certifications (SOC 2, HIPAA, GDPR-ready, etc.).

​@RanjithR1 Absolutely No No when it comes to storing PII data in AEM. Is there any specific use case that forces this direction ? 

Hi ​@RanjithR1  

When you are talking about PII data, could you elaborate what kind of PII data are we talking about here?

Hi ​@RanjithR1 

When you are talking about PII data, could you elaborate what kind of PII data are we talking about here? As you are aware AEM is a CMS and we use the system to store content, not always public. For any critical content, we always secure our website with Login and Access Management.

PII is a broad term and can mean very different things in different contexts. For example:

• A form submission with name and email stored in AEM
• User profile data synced from a CRM into AEM
• Analytics or behavioral data tied to a user identity
• Healthcare or financial data which falls under stricter compliance like HIPAA or PCI-DSS
• Employee data stored in an intranet built on AEM

Each of these has a completely different architectural answer, so it would be difficult to give you the right direction without understanding your use case better.

On a high level what I can tell you and what I have seen across different clients and projects, we use AEM for

• Storing and rendering public content on websites
• Storing and rendering secure, gated content using login mechanisms
• Storing assets, public and non public — depending on the same you may or may not have login and access mechanism

We do not use AEM for

• Storing user information
• Storing data like a DB
• Storing any CRM information
• and many more

If you read the Adobe AEMaaCS Security Overview, it clearly mentions that data in transit is protected by TLS 1.2 and all data at rest is encrypted by the cloud service provider. For them the service provider for Cloud is Azure. In Azure documentation they have clearly mentioned they use AES-256.

Could you share more context — what type of PII are we talking about, what is the source of this data, and what compliance requirements like GDPR, HIPAA, or PCI are you working within? That will help give you the most accurate architectural guidance.

Thanks

Veena