How Membership Management Systems Support Member Data Compliance and Business Rule Governance

How Membership Management Systems Support Member Data Compliance and Business Rule Governance

A membership system may store identity information, contact details, transaction records, points, coupons and service information at the same time. Once these data are connected to store POS, mini programs, e-commerce platforms and beauty advisor tools, the brand must clarify where each item comes from, what business purpose it serves, which roles can access it, and how it should be handled after a member closes an account.

Member data governance requires brand policies to be translated into objects that the system can execute and record. These include registration source, processing basis, notice and consent records, field purposes, access permissions, retention periods, account-closure status, benefit settlement, rule history and operational logs. This allows the system to reconstruct the source, use and changes of member data across different business processes.

PEKON’s CRM Membership Center supports member identity, membership levels, points, benefits and multi-touchpoint data, while implementing permissions, interfaces and operational records according to the brand’s policies. China’s Personal Information Protection Law includes collection, storage, use, processing, transmission, provision, disclosure and deletion within the scope of personal information processing, and requires processing purposes to be clear and reasonable, with collection limited to what is necessary. A membership system can create executable permissions, processes and records, while legal interpretation, policy development and compliance responsibility remain with the brand and its professional advisors.

PEKON’s confirmed product capabilities include member identity, membership levels, points, benefits, data connections, permission control and basic operational records. Notice and consent versions, account-closure processes, retention-period tasks, deletion or anonymization, cross-system status returns and audit queries should be separately confirmed during the project as standard functions, parameter configurations, interface integrations, custom development or unsupported items.

Record Identity, Notices, Consent and Processing Bases Separately During Registration

When a member registers, the system should create a member number while also recording the registration entry point, registration time, identity identifier, account status and the version of the personal information policy applicable at that time. Where processing is based on individual consent, the system should record the consent time, channel, applicable purpose and current status. Where information is processed to perform a contract or on another lawful basis, the relevant scope should be recorded according to the processing basis confirmed by the brand.

After a member withdraws consent, processing that depends on that consent should stop. If the original processing purpose, method or types of personal information change, the brand should provide a new notice or obtain new consent according to the applicable rules. Data that has another lawful processing basis may continue to be processed for the corresponding purpose. It should not simply be handled as “all data must be deleted after consent is withdrawn.” Withdrawal of consent does not affect the validity of processing activities already carried out before the withdrawal.

The same member may leave a mobile number, membership card number, WeChat identity or e-commerce account at different touchpoints. OneID can connect these identity records within the same brand, but the association must use identifiers and matching rules approved by the brand, while handling phone-number changes, duplicate registrations and identity conflicts. In a multi-brand group, each brand’s membership system, processing basis and data boundaries should be managed separately.

For how stores use member identity and necessary information during reception, transactions and benefit redemption, see Connecting Beauty Membership Management Systems with Store Services. This article focuses on how the brand defines the source, purpose, permissions and audit requirements before the information enters store operations.

Before connecting multiple systems, the data-processing relationship among all parties must also be clarified. The brand normally determines the purposes and business rules for processing member data. In an entrusted-processing scenario, PEKON provides software and processing support according to the contract and implementation scope. Whether PEKON, an e-commerce platform, an SMS provider or another external organization acts as an entrusted processor, joint processor or independent processor must be determined based on whether each party decides the processing purposes and methods, as well as the actual cooperation relationship. An interface can transmit data, but it cannot replace agreements on field scope, retention periods, security measures and deletion responsibilities.

Define Information Purpose and Usage Scope at Field Level

Member fields should not be designed only around “what can be collected.” They should also explain why the information is collected, who uses it and how long it is retained. A mobile number may be used for identity recognition, login verification or service contact. Birthday information should enter the business scope only when it is actually used for birthday benefits or related services. Purchase records may support after-sales inquiries and member services. Skin type, shade preferences and other service information should be defined according to their actual purposes, processing bases and access scope.

A field-to-purpose relationship can be established so that every member data item can be traced back to a clear processing purpose:

After data enters the CRM, it should not automatically be made available to every department and store. Headquarters, regional teams, stores, customer service, beauty advisors and technical operations require different data scopes. Query, modification, export, batch processing and manual adjustment should be authorized separately. When the CRM exchanges data with POS, mini programs, e-commerce platforms or data platforms, interface fields and calling purposes must also be included in permission and usage management.

Use Rule Versions to Track Points and Benefit Results

Membership levels, points and benefits are defined by the brand. The system turns confirmed policies into calculation, issuance and usage rules. This article focuses on how changes and execution bases are retained after rules are published, rather than designing membership levels, points ratios or benefit content for the brand.

A traceable rule record should include the version number, effective time, applicable members and channels, change details, operator and publication result. Where rule publication requires approval, the approval process should also be retained. When a member is upgraded, points are added or deducted, or a benefit is issued, the relevant account ledger and business document should correspond to the rule version effective at that time. Later rule changes should not overwrite historical facts.

Manual adjustments also require records. When customer service issues additional points, an operations employee extends a coupon’s validity period or a store handles an exceptional benefit, the system should record the status before and after adjustment, the reason, the operator and the related business record. This explains why a member account changed and distinguishes system-generated results from manual processing.

Connect Account Closure with Benefit Settlement and Historical Records

Member account closure involves request acceptance, identity verification, checks for unfinished matters, benefit processing, data disposal and result notification. The system should first record the request source, request time and processing status, then check unfinished returns and exchanges, after-sales services, points, coupons and unfulfilled member benefits. How benefits are used, expired or settled should follow the membership policy published by the brand and the agreement with the customer.

After account closure is completed, the member account should no longer allow login, and member-operation and marketing-related processing should stop at the same time. Information that must be deleted should be handled according to the confirmed rules. Where a statutory retention period has not expired or deletion is temporarily technically difficult, the system should retain only storage and necessary security protection, without using the data for member marketing, profiling, outreach or other business processing. Whether historical transactions, refunds and after-sales records remain stored should be determined according to applicable laws, financial requirements and business responsibilities.

Member account closure should not be understood as immediately clearing every associated record. The system must distinguish account status, member-operation information, historical transactions, benefit ledgers and audit records, and handle each according to its purpose, retention basis and responsible party. Anonymization means that the information can no longer identify a specific individual and cannot be restored. General de-identification should not be treated as equivalent to anonymization.

Define Deletion, Retention and Access Permissions by Data Object

The retention period for member data should correspond to the actual processing purpose. Information still needed to provide membership services should be managed during the valid membership relationship. Transaction, refund and after-sales records should be retained according to relevant business and regulatory requirements. Notice and consent records, account-closure records, rule histories and operational logs explain historical processing. Duplicate, invalid or expired data with no other retention basis should enter a deletion or anonymization process.

System design can record the retention basis, start time, expiry action and responsible role for each data object. Whether expiry actions are executed by system tasks or reviewed by business staff should be confirmed according to the product version, data architecture and implementation scope. After processing is completed, the system should also record the object, time, execution method and result.

When data is distributed across CRM, POS, mini programs, e-commerce platforms and data platforms, each system should perform deletion, processing suspension or retention according to its confirmed responsibilities and return the result. The CRM may initiate or record a related task, but changing the member’s front-end status cannot replace data processing in every downstream system. The handling responsibility for independent systems and historical copies must be determined according to the agreements and actual data relationship among the parties.

Access permissions should consider organization, role, field and operation type at the same time. Store beauty advisors should view only the information needed to serve current customers. Customer service staff should access the account and business records relevant to a request. Headquarters operations teams should manage rules and member groups within their authorized scope. Technical staff handling system issues should also be restricted by necessary data scope and operational logs. High-impact operations such as batch export, identity merging, manual benefit adjustment, account closure, deletion and permission changes require stricter permissions and records.

In addition to permissions and logs, the membership system should apply appropriate security measures based on data type and risk. PEKON has publicly confirmed support for encrypted transmission, sensitive-field encryption and tiered permission control. Where personal information is sensitive, used for automated decision-making, entrusted to another processor or provided to another personal information processor, the relevant processor should conduct a personal information protection impact assessment before processing and retain records. The responsible parties for specific encryption scope, masking methods, log retention periods, security incident procedures and assessment materials should be confirmed according to the product version, actual roles and implementation scope.

Reconstruct Processing Through Logs, Rule Versions and Business Ledgers

Audit records in a membership system can cover account creation, changes to identity associations, notice and consent status changes, rule publication, manual benefit adjustments, data exports, account-closure processing, deletion and anonymization. Each record should at least indicate who performed what operation, on which object, at what time and through which entry point, what changed before and after the operation, and whether processing succeeded.

Rule versions answer “which policy was applied at the time.” Operational logs answer “who did what.” Member accounts and transaction ledgers answer “what was the business result.” When the three types of records are connected through a shared member number, business document number, rule version or task number, the brand can trace the complete process behind a points change or an account-closure request.

China’s Measures for the Management of Personal Information Protection Compliance Audits, which took effect on May 1, 2025, and its supporting guidance include lawful processing bases, notices, retention periods, deletion, account closure, individual-rights responses, security measures and impact assessments within the review scope. A membership system can provide data, status and log records, while the final audit judgment must be made by the client’s internal body or a professional organization.

Audit frequency is not determined solely by whether a company is listed. It should be assessed according to the scale of personal information processing, the types of data subjects and other applicable rules. The Measures provide that a personal information processor handling the personal information of more than 10 million individuals must conduct a compliance audit at least once every two years. A 2026 policy Q&A from China’s Cyberspace Administration further explains that the threshold includes the stated number. According to relevant national standards, processors handling more than 1 million but no more than 10 million individuals should conduct an audit at least once every three or four years, while processors handling no more than 1 million individuals should conduct an audit at least once every five years. Special circumstances involving minors and other protected groups should follow the applicable rules.

A listed company does not automatically become subject to a separate set of membership data-processing rules solely because it is listed. Such clients often have more membership touchpoints, system interfaces and internal-control requirements, so system development must also consider business continuity, permission management, audit evidence and corporate governance.

How Large Brands Turn Governance Requirements into System Requirements

Large brands often have many membership touchpoints, internal roles and connected systems. The same governance requirement may affect CRM, POS, mini programs, e-commerce platforms and data platforms at the same time. System development should first determine who is responsible for member identity, benefit processing, data retention, account closure and operational records, and then define how each system executes and returns the relevant results.

These projects usually begin by mapping master records and interface relationships among the CRM, POS, mini program, e-commerce platform and related data systems. Governance requirements are then converted into system objects and processing statuses. Design and development may cover member identity models, notice and consent records, field purposes, account status, benefit settlement, rule versions, retention periods, permission matrices, operational logs and audit queries, together with status synchronization and exception handling across touchpoints.

Pre-launch testing can cover registration and notice/consent, duplicate identity handling, consent withdrawal, rule changes, manual benefit adjustments, account-closure requests, suspension of historical processing, data deletion or anonymization, and log tracing. Each requirement should be classified as a standard function, parameter configuration, interface integration, custom development or unsupported item. This avoids replacing product and implementation verification with a general statement that the system “supports compliance.”

The exact compliance scope must be confirmed based on the client’s policies, data architecture, existing systems and implementation requirements. PEKON provides membership products, system design and development support. It does not replace the client’s legal judgment, internal policy development, compliance audits or certification work, and no single system should be assumed to cover every legal requirement.

Give Every Member Data Item a Source, Purpose and Processing Record

Member data governance should ultimately enable the system to answer several practical questions: Through which entry point did the member register? Which version of the personal information policy applied at that time? On what basis was the processing carried out? Why was a particular item collected? Which people and systems used it? Which rule version caused a membership-level, points or benefit change? After account closure, which data was deleted or processing was stopped, and which historical records still need to be retained?

Based on the CRM Membership Center, PEKON incorporates member identity, membership levels, points, benefits, data connections, permissions and basic operational records into system development. After the brand defines its policies and responsibility boundaries, the implementation method for notices and consent, account closure, retention periods, deletion, cross-system returns and audit queries can be confirmed according to actual requirements. This allows the requirements to reach stores, member entry points and other business systems.

If your brand is reviewing member registration, notice and consent, account closure, data retention or audit requirements, you can bring your existing membership policies, field list and system architecture to discuss the scope of standard functions, parameter configuration, interface integration and custom development with a PEKON consultant.