Security, Account Access and Incident Response Policy

Security controls are intended to protect the confidentiality of restricted information, the integrity of records and decisions, and the availability of systems needed to operate the service.

A control may protect more than one objective. For example, access restrictions may protect both confidentiality and record integrity.

Security measures should reflect the nature, sensitivity, volume and purpose of the information; the number and type of affected persons; the likelihood and severity of harm; and the cost and effectiveness of available safeguards.

Identity documents, guardian records, payment evidence, administrator credentials and security logs require stronger protection than ordinary public website content.

6membership should not rely on one safeguard as the sole protection for a sensitive operation.

Security may combine authentication, authorisation, server-side validation, database rules, encrypted transport, monitoring, audit logging, rate limits, provider controls and administrative review.

A person, service or process should receive only the access reasonably required for the assigned role and period.

Access must not be granted broadly for convenience where a narrower permission can support the required work.

New systems and functions should default to private, restricted and non-public operation until the required permissions and publication conditions are satisfied.

Sensitive information must not become public merely because a field, storage object or route was created without an explicit restriction.

Automated security signals may assist detection and prioritisation but must not be treated as infallible evidence.

Material restrictions, fraud findings and breach decisions should receive appropriate human review unless an immediate temporary safeguard is required.

The Privacy Notice governs personal-information processing.

The Acceptable Use Policy governs technical abuse and prohibited conduct.

The Authority Requests Policy governs disclosures to competent authorities.

6clement Joshua, as operator of 6membership, is responsible for establishing an appropriate production security framework and ensuring that security responsibilities are assigned.

Operational responsibility may be delegated, but accountability must not disappear merely because a provider or contractor performs part of the work.

A designated authorised person should coordinate security controls, incident assessment, provider escalation, evidence preservation and recovery decisions.

The responsible person must have sufficient access to investigate incidents without receiving unrestricted access unrelated to the role.

Administrators must use access only for authorised application, membership, payment, refund, complaint, privacy or security work.

An administrator must report suspected compromise, accidental disclosure, incorrect permission or unusual system behaviour promptly.

Approved providers may operate infrastructure, databases, email delivery, network protection, payments and other assigned functions.

Provider involvement does not remove the need to configure the service securely, limit information sharing and respond appropriately to provider incidents.

Where a provider processes personal information on behalf of 6membership, the applicable arrangement should address confidentiality, security, authorised processing, incident notification, subprocessors, deletion and assistance with rights or regulatory obligations.

Provider security statements and default settings must not be treated as a substitute for reviewing the actual 6membership configuration and enabled services.

A contractor or temporary collaborator must receive a defined role, appropriate confidentiality obligations and time-limited access where possible.

Access must be removed when the work ends or the person no longer requires it.

Persons handling applications, payments, identity records and administrative tools should receive appropriate instruction concerning phishing, credential protection, privacy, secure communications, suspicious requests and incident reporting.

Security responsibilities, access permissions, providers, secrets, backup arrangements and incident procedures should be reviewed periodically and after a material change or incident.

The public website includes pages intended for visitors, membership information, legal policies and authorised public verification.

Public access does not include permission to access private application, database, storage, payment or administrative functions.

The application system includes forms, saved records, identity evidence, guardian approvals, policy acceptances, payment handoff and application-status communications.

Access to one application must not provide access to another applicant’s record.

Where member access is provided, it may include current status, cards, certificates, renewal information and authorised membership records.

Public verification remains separate from private member access.

The administrative console includes sensitive controls for application review, approval, decline, incomplete flags, custom observations, payments, refunds, membership status and audit records.

It must not be exposed as an ordinary public route without strong authentication and authorisation.

Connected provider systems may include hosting, database, storage, email, network, identity-support and payment services.

Each provider must be used only for its authorised production role and configured according to the provider’s security requirements.

Flutterwave is the selected production payment integration. Vercel, Supabase, Resend, Cloudflare and authorised Google or Gmail services support the presently documented infrastructure and communication functions.

A new provider must not receive production information merely because its integration exists in development code or an unfinished interface.

Development, test and production environments should be separated appropriately.

Real identity documents, live payment credentials and unrestricted production data must not be copied into an insecure test environment without a necessary and lawful reason.

Users should access 6membership through the authorised domain and approved subdomains.

A confusing domain, cloned website or unofficial payment page should be treated as suspicious.

Access to a private application or membership record must be linked to an authenticated or otherwise securely verified person.

Possession of an Application Reference or Membership ID alone should not provide unrestricted private access.

Secure links may be used for email verification, guardian consent, application actions and other defined purposes.

A secure link should be difficult to guess, purpose-limited, time-limited where appropriate and invalidated after completion or security revocation.

An OTP may confirm control of a communication channel or authorise a specified action.

The OTP must not authorise unrelated activity, remain reusable indefinitely or be stored in usable plaintext longer than operationally necessary.

Application and membership lookup functions should avoid revealing whether arbitrary private identifiers, emails or accounts exist.

Rate limits, generic responses and other safeguards may be applied to reduce automated discovery.

Authenticated sessions should expire after an appropriate period, use protected session data and be invalidated where compromise is suspected.

Sensitive actions may require renewed verification even where an ordinary session remains active.

A person using a shared device should sign out, close sensitive pages and avoid saving private files or credentials.

6membership cannot prevent another device user from viewing information that the applicant deliberately leaves accessible on the device.

A person who loses access to the registered email or authentication method may be required to complete additional identity verification.

Recovery must not rely solely on information that is easily public or already displayed on a membership card.

Each administrator should use an individually attributable account rather than a shared generic credential.

This allows sensitive decisions and access events to be connected with the person who performed them.

Administrator roles should distinguish super-administration, verification, application review, privacy, security, payment and other responsibilities where practical.

A verification administrator should not automatically receive every super-administrator capability.

Administrative access should use strong authentication appropriate to the sensitivity of the console.

Multi-factor authentication should be enabled where supported and should be required before full production access is granted.

High-impact actions may require renewed authentication, an explicit confirmation step or another protective control.

Examples include issuing refunds, changing administrator roles, revoking memberships, exporting records and altering production security settings.

Approve, decline and incomplete actions must use defined status transitions and server-side permission checks.

A custom administrator message must not be able to change the actual payment, refund or membership status by wording alone.

Material actions should record the administrator, action, application or membership, previous status, new status, reason, custom observation, timestamp and resulting communication status.

Audit records must not be editable casually through the ordinary review interface.

Routine application and membership decisions should use controlled administrative functions rather than unrecorded direct database edits.

An emergency correction performed outside the ordinary interface must be documented and reconciled with the audit history.

Administrator access must be removed promptly when the person leaves the role, loses authority or presents a material security risk.

Relevant sessions, tokens and credentials should be revoked.

Where passwords are used, they must be protected through an appropriate authentication system and must not be stored as readable plaintext.

Users and administrators should use unique, difficult-to-guess credentials and should not reuse sensitive passwords across unrelated services.

A person must not share an administrator password, OTP, session, recovery code or protected access link with another person.

Delegating work does not justify sharing a credential where a separate authorised account can be created.

Authentication and verification routes may use rate limits, temporary blocks, progressive delays, risk checks and monitoring to reduce guessing and automated attacks.

Protective controls should avoid unnecessary permanent exclusion of legitimate users.

Credentials and secrets should be rotated after suspected exposure, relevant staff changes, provider compromise or another event that materially affects trust.

Routine rotation may also be applied according to risk and provider capability.

Account recovery should verify the requester sufficiently before changing an email address, resetting authentication or granting access.

Recovery information must not reveal existing credentials or private record contents unnecessarily.

6membership may revoke active sessions and secure links following a password change, suspicious login, administrator removal, security incident or user report.

Passwords, private keys and complete secret credentials must not be sent through ordinary email.

A temporary secure link may be emailed where the link is appropriately protected and purpose-limited.

Secret API keys, database administrative credentials, Flutterwave access tokens, encryption keys, webhook-signature secrets, private service credentials and other privileged authentication material must remain server-side.

They must not be included in browser code, public repositories, screenshots, client-visible errors, downloadable assets or applicant-facing communications.

A value labelled public or publishable must be checked against the provider’s documentation before client use and must never be substituted for a secret credential.

A credential designated by a provider as publishable may be used only for the limited public purpose for which it was issued.

A publishable key must not be treated as authority to perform privileged database, payment or administrative operations.

Production credentials should be stored through protected environment configuration or an appropriate secret-management facility.

Local development files containing secrets must remain excluded from public source control.

Where supported, a credential should be restricted to the minimum service, environment and permissions required.

Development credentials must not receive unnecessary production capability.

Logs and error reports must avoid recording complete secrets, authentication headers, payment credentials, usable secure tokens and full OTP values.

A credential that may have been exposed must be treated as compromised until assessed.

Protective action may include revocation, rotation, log review, access restriction and provider notification.

Secrets must not be committed to a public or shared source-code repository.

Removing a secret from the latest file does not remove it from earlier repository history; the credential must still be rotated.

Eligibility, tier, billing, age, guardian, payment, status and administrative permissions must be validated by trusted server-side logic.

Browser values, query parameters and hidden form fields must not be accepted as final authority.

Private database and storage access should be denied unless an explicit authorised route permits the action.

Creating a record does not mean every signed-in or anonymous person should be able to read or modify it.

Row-level and equivalent database protections should be used where appropriate to restrict records by person, role and operation.

Server-only administrative credentials must not be used directly from the browser to bypass those protections.

A privileged database credential may perform operations beyond ordinary user permissions and must therefore be restricted to controlled server functions.

Every route using privileged access must validate the requester, requested action and affected record.

Application, payment, refund and membership statuses should follow defined transitions.

A user or administrator must not be able to move directly to an impossible or unauthorised state merely by submitting a different status string.

Payment confirmations, webhook events, email triggers, refunds and other repeatable operations should use idempotency or equivalent duplicate protection.

Receiving the same valid event more than once must not create multiple memberships, refunds or conflicting decisions.

Payment operations should preserve unique internal references, provider transaction identifiers, webhook event identifiers and idempotency references where supplied or generated.

A retry after a timeout must reconcile the existing operation before creating a replacement transaction or refund.

Application References, Membership IDs and privacy-request references should be generated through an authorised server process.

References must not be accepted as proof that a record was approved, paid or active.

Information should be classified according to its sensitivity and operational purpose.

Identity documents, guardian evidence, payment and refund records, security logs and administrator notes require restricted handling.

Sensitive information should be transmitted through encrypted network connections supported by the production service and approved providers.

Users should not submit identity or payment information through an unofficial or unencrypted route.

Production databases and storage should use the provider’s appropriate security and encryption capabilities.

Encryption does not replace access controls, because an authorised service can still decrypt or display information when permissions are misconfigured.

Identity, age, guardian and supporting documents must be stored privately and accessed through authorised server or signed-access mechanisms.

Private documents must not be placed permanently in a public storage location.

Public card and verification derivatives should remain separate from original private uploads.

Making a limited card photograph public must not expose the source document or original full-resolution image.

Critical records should be supported by appropriate provider backup, recovery or replication arrangements.

Backups must remain subject to access restrictions and retention controls.

Recovery procedures should be tested sufficiently to establish that required records can be restored.

Deletion should remove information from active systems where required and technically appropriate.

Provider backups, audit records and legal holds may follow separate deletion schedules described in the retention framework.

Upload routes should accept only the file types and sizes reasonably required for the relevant application purpose.

A filename or browser-supplied file type must not be trusted as the sole confirmation of actual file content.

Uploaded files may be inspected for format, size, consistency and indicators of malicious or deceptive content.

A file may be rejected or quarantined where it cannot be processed safely.

Private files should use controlled storage identifiers rather than relying on the original filename as the storage path.

User-supplied filenames must not be allowed to escape the intended storage location or overwrite another person’s file.

An application document upload must not execute as code on the server or in another user’s browser.

Active content and embedded behaviour should be restricted or processed safely.

Image and document metadata may be removed or limited where it is unnecessary for verification and could expose device, location or other private information.

Only authorised reviewers should be able to retrieve private application documents.

A document link must not remain permanently accessible to anyone who obtains or guesses its path.

Uploaded documents should be retained only for the period required for application review, membership administration, fraud prevention, complaints, legal obligations and claims.

Flutterwave is the authorised production payment provider for 6membership payments.

Applicants and payers must complete payment only through the official checkout initiated by the 6membership website.

Flutterwave secret credentials, access tokens, encryption keys, webhook-signature secrets and other privileged payment configuration must remain in protected server-side configuration.

A protected payment credential must not appear in browser code, public environment variables, client logs, source-code repositories, applicant emails or administrator observations.

Credential access should be limited to the server functions that initialise, verify, reconcile or refund transactions, and suspected exposure requires immediate rotation and investigation.

A browser callback, success page, screenshot, debit alert, applicant-supplied reference or webhook payload is not by itself final proof of payment.

Before an application is treated as paid or membership value is provided, the server must re-query Flutterwave through an authenticated verification endpoint and compare the response with the expected internal transaction.

Where a webhook is delayed or unavailable, a controlled reconciliation or polling process may verify pending transactions without relying on the applicant to repeat payment.

Verification should confirm that the provider status is successful and that the provider transaction identifier, internal transaction reference, amount, currency and relevant customer or application relationship match the expected record.

The customer email or other provider-returned identity field may be compared where appropriate, but it must not override the verified application relationship.

A successful payment for the wrong amount, currency, reference, customer or application must not be accepted automatically and must enter a controlled review or reconciliation state.

Incoming Flutterwave webhook events must be authenticated using the signature configured for the production account and the provider-supported verification method.

An unsigned, invalid, malformed or replayed event must not change payment, refund, application or membership status.

Webhook authentication confirms that the event was sent through the expected provider channel; it does not replace independent transaction verification before value is granted.

The payment system must tolerate repeated callbacks, webhook deliveries, verification responses and administrator retries without issuing duplicate value, applications, receipts or refunds.

Provider and internal transaction identifiers should be recorded uniquely where appropriate.

Refund and payment requests should use unique trace or idempotency values where the Flutterwave operation supports them, and the result of an earlier request should be reconciled before another request is sent.

A refund must be initiated only by an authorised server or administrator process connected with the verified original transaction.

The process must verify the refundable amount, reason, original transaction, prior refund history, chargeback state and administrator authority before submission.

A refund request must not redirect funds to an unrelated destination merely because a custom message contains different payment details.

The refund operation should use duplicate protection so that an administrator retry or provider timeout does not create multiple reimbursements.

6membership must distinguish an internally approved refund, a request submitted to Flutterwave, provider acceptance, a pending or processing state, provider-reported success or completion, and failure or rejection.

A communication must not claim that a refund was initiated where Flutterwave has not accepted the instruction.

A communication must not claim that the payer has received the money merely because Flutterwave reports completion, because the receiving financial institution may require additional posting time.

6membership should maintain a controlled reconciliation process for pending, conflicting, delayed or missed payment and refund events.

The process may query Flutterwave using the provider transaction identifier or internal transaction reference and compare the result with the application, payment and refund records.

A reconciliation job must remain idempotent and must not grant value merely because a previously missing event later appears.

6membership payment records and logs should retain only the information needed for verification, reconciliation, refunds, disputes, accounting, fraud prevention and legal obligations.

Complete card numbers, card security codes, banking passwords, payment PINs and payment OTPs must not be stored as ordinary 6membership records.

Flutterwave responses must not be logged indiscriminately where they contain information unnecessary for the operational purpose.

Application, administration, privacy and security messages should use authorised 6membership addresses and configured sending services.

A display name alone does not prove that a message is authentic.

Ordinary email should not contain complete identity documents, full payment credentials, passwords, reusable OTPs or unrestricted private-access tokens.

A secure link may be used where access to sensitive information is required.

Email links used for verification, guardian consent, corrections and other protected actions should identify the intended action, expire appropriately and become invalid after completion where practical.

A custom administrator observation must be treated as untrusted text and rendered safely.

It must not be allowed to inject executable code, alter email templates, create unauthorised links or override required legal wording.

Email records may distinguish generated, queued, provider-accepted, delivered, bounced, rejected and complained-about messages.

A sent or delivered status does not prove that the recipient personally read or understood the communication.

Official messages must not request that applicants send passwords, payment PINs or OTPs to an administrator.

Unexpected payment, refund, credential or identity-document requests should be verified through the official website or address.

Appropriate domain, DNS and email-authentication controls should be configured to reduce spoofing and unauthorised sending.

Configuration should be reviewed after changes to the domain, email provider or sending route.

Form, route, query, webhook and API inputs must be validated according to the expected type, length, format and allowed values.

Client-side validation improves usability but does not replace server-side validation.

Applicant names, custom messages, complaints and other user-provided text must be rendered in a manner that prevents executable content from being interpreted as trusted application code.

State-changing routes should use appropriate protections against forged, replayed and unauthorised requests.

The presence of a valid URL alone must not authorise a sensitive administrative action.

Public error messages should remain useful without exposing stack traces, database structure, credentials, private provider responses or internal security decisions.

Detailed diagnostics may be recorded securely for authorised investigation.

Rate limits and abuse controls may be applied to authentication, verification, application submission, payment, public lookup, privacy requests and administrative actions.

Controls should consider legitimate retries and accessibility requirements.

Application frameworks, packages, runtime components and provider integrations should be maintained and reviewed for relevant security updates.

An update should be tested appropriately before production deployment, particularly where it affects authentication, payments or data access.

Production deployments should use an authorised process and should not expose local files, development routes, test secrets or unfinished administrative controls.

A release introducing a material security regression should be rolled back or corrected promptly.

Appropriate browser and response controls may be used to reduce framing, content injection, transport downgrade and unnecessary information exposure.

The exact configuration may vary according to the production architecture.

Security records may include authentication events, administrator actions, provider callbacks, failed permission checks, unusual request patterns, credential changes and incident-response actions.

Approve, decline, incomplete, refund and membership-status actions should be recorded with the relevant administrator and status transition.

The audit record should remain distinct from the applicant-facing custom message.

Payment logs may contain internal references, Flutterwave transaction identifiers, verified status, amount, currency, webhook event identifiers, signature-validation outcome, verification attempts, refund references and reconciliation results.

Logs should distinguish an event received from an independently verified transaction outcome.

Complete payment-card credentials, banking passwords, payment PINs, payment OTPs and usable Flutterwave credentials must not be recorded by 6membership application logs.

Logs should contain enough information for accountability and investigation without becoming an unnecessary duplicate database of sensitive personal information.

Secrets, full documents and unrestricted secure tokens should be excluded or redacted.

Logs should use sufficiently reliable timestamps and event identifiers to reconstruct material actions.

Where provider and internal clocks differ, the review should preserve both records rather than altering one silently.

Security and audit logs should be accessible only to authorised persons whose role requires them.

A person whose action is being investigated should not be able to delete the relevant evidence through the ordinary interface.

6membership may use provider alerts, application monitoring and review rules to identify outages, errors, suspicious logins, failed webhooks, unusual administrative actions and other security concerns.

An alert is an investigation signal and not automatically proof of wrongdoing.

Security-sensitive code, database rules, administrative routes, payment handlers and access controls should be reviewed before production release and after material changes.

Relevant provider and dependency advisories should be assessed according to exploitability, exposure, affected information and available mitigation.

Not every published issue affects the actual production configuration.

A vulnerability should be prioritised according to the likelihood and severity of exploitation, the affected systems and available protective controls.

A critical issue affecting authentication, payments or private records may require immediate restriction or deployment.

A person who discovers a potential vulnerability should report it privately through the official security channel and provide enough information to reproduce or assess the issue.

The reporter should avoid unnecessary access to personal information and service disruption.

A vulnerability report does not authorise data extraction, persistence, extortion, denial-of-service activity, credential attacks, social engineering or public disclosure of an exploitable issue before reasonable remediation.

6membership may acknowledge a credible report and may request clarification or additional evidence.

The service does not promise a reward, employment or public recognition unless a separate programme states those terms.

A public disclosure timeline should consider the risk to users, remediation progress, provider involvement and applicable law.

Confidential security details may remain restricted after remediation where disclosure would create continuing risk.

A security event is an observable occurrence that may be relevant to system, account or information security.

Examples include a failed login, unusual request, provider alert, incorrect permission, exposed credential or suspicious email.

A security incident is an event or group of events that compromises or credibly threatens confidentiality, integrity, availability, authentication or authorised operation.

An incident may exist without involving personal information.

A personal-data breach involves accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal information.

An incident must be assessed to determine whether this definition and applicable notification thresholds are met.

Severity may reflect the affected systems, information sensitivity, number and type of persons, duration, exploitation, financial impact, safety consequences and effectiveness of containment.

A provider alert or unusual event may be determined not to involve compromise after investigation.

The conclusion and supporting evidence should be recorded where the event was material enough to trigger formal review.

Incidents presenting ongoing access, payment, identity, child-safety or high-risk privacy consequences should receive urgent containment.

Lower-risk events may follow the ordinary investigation queue.

An event may be escalated to the operator, security lead, privacy contact, provider, professional adviser or competent authority according to its nature and legal requirements.

Immediate action may include revoking sessions, rotating credentials, disabling links, restricting administrator access, pausing a payment route, isolating affected functions or applying provider controls.

For a payment incident, containment may include disabling checkout initiation, rejecting webhook processing temporarily, rotating Flutterwave credentials or signatures, reconciling affected transactions and preventing duplicate refunds or membership activation.

Containment should reduce ongoing harm while preserving necessary evidence.

Relevant logs, provider notices, message headers, database records, files, timestamps and administrative actions may be preserved.

Evidence must not be altered to make the incident appear less serious or to attribute it falsely.

The investigation should determine what occurred, when it began, how it was detected, which systems and persons were affected, whether access continued and what information or operations were involved.

Eradication may include removing malicious content, correcting permissions, replacing vulnerable code, invalidating tokens, rotating keys and addressing the cause of compromise.

Affected functions should return to production only when sufficient confidence exists that the immediate threat has been controlled.

Recovery may occur in stages and may include enhanced monitoring.

Affected persons may be advised to reset credentials, verify payments, disregard fraudulent messages, monitor accounts or take another practical step.

Advice must reflect the actual incident and must not transfer responsibility unfairly to the affected person.

After containment and recovery, 6membership should assess root causes, control failures, provider performance, response effectiveness and required policy or technical changes.

A person must not destroy evidence, alter logs, misstate the affected scope or delay required escalation to protect themselves from accountability.

A confirmed personal-data breach must be assessed according to the nature, sensitivity and volume of information; the number and circumstances of affected persons; the likely consequences; and the effectiveness of encryption, de-identification and other mitigation.

Where a personal-data breach is likely to result in a risk to the rights and freedoms of individuals, 6membership will notify the Nigeria Data Protection Commission within 72 hours of becoming aware of the breach, in accordance with section 40 of the Nigeria Data Protection Act 2023 and the General Application and Implementation Directive 2025.

Where complete information is not available immediately, available information may be supplied in phases without undue delay, together with the explanation required by the applicable framework.

Where the breach is likely to result in a high risk to an affected person’s rights and freedoms, 6membership will communicate the breach to the affected person immediately after becoming aware of it where the applicable Nigerian framework requires that notification.

The communication should use plain and clear language and include practical steps the person may take to reduce possible harm.

Where another applicable law uses a different notification threshold or timetable, the legally applicable requirement will be followed.

Where applicable, a breach notice should describe the nature of the breach, the relevant categories of information and persons, likely consequences, contact point and measures taken or proposed to address and mitigate the incident.

Information may be limited where disclosure would create an additional security risk or violate law, but the notice must still satisfy applicable requirements.

Where direct communication would involve disproportionate effort, expense or is otherwise not feasible, an appropriate public communication may be used where permitted by applicable law.

A public statement must not expose additional personal information.

Where an approved processor or provider reports a relevant breach, 6membership will request and assess the information needed to meet its own responsibilities.

Provider notification does not remove 6membership’s obligation to determine the effect on its applicants and members.

Where an incident concerns Flutterwave, 6membership should identify whether checkout initiation, webhooks, transaction verification, refunds, settlement data, payer information or payment credentials were affected and should coordinate containment and evidence collection through authorised provider channels.

Provider statements must be assessed against the 6membership configuration and records rather than repeated publicly without verification.

6membership will maintain a record of personal-data breaches, including the facts, effects, assessment, notifications and remedial actions, in a form supporting accountability and regulatory verification.

6membership must not claim that no information was accessed, no person was affected or an incident was fully resolved before the available evidence supports the statement.

A person should protect the email address used for applications and membership because it may receive secure links, status notices and recovery communications.

Loss of email access should be reported promptly where it affects an active application or membership.

Users should apply reasonable device protections, updates and screen locks and should avoid completing sensitive actions on an untrusted or public device.

A person should verify the official domain and expected transaction before entering application, identity or payment information.

A similar-looking website or social-media payment link must not be assumed to be official.

Users must not disclose passwords, PINs, OTPs or secure-link tokens to another applicant, member, administrator or caller.

A person should report unexpected OTPs, unknown applications, suspicious payment messages, altered records, unauthorised access and other credible security concerns promptly.

The report should include relevant evidence without sending complete passwords or banking credentials.

6membership may restrict access, a secure link, application, card or membership temporarily while an unauthorised-use report is reviewed.

The restriction is protective and does not automatically determine fault.

Recovery may require identity confirmation, contact verification, credential replacement, payment review and revocation of older access methods.

A recovery request must not transfer private records to an unverified person.

A user’s security responsibilities do not excuse inadequate controls, unlawful disclosure or another failure for which 6membership or a provider is legally responsible.

Security records may include access events, administrator actions, incident reports, provider notices, affected-system information, evidence, breach assessments, remedial actions and communications.

Records may be retained for security monitoring, investigation, accountability, provider management, legal obligations, complaints and claims.

Retention should remain proportionate and subject to legal holds and deletion requirements.

Incident evidence, exploitable technical details, administrator credentials and investigative material may remain confidential where disclosure would compromise security, privacy, legal privilege or a lawful investigation.

Phishing, impersonation, exposed credentials, suspicious links, unauthorised access, payment fraud and potential vulnerabilities may be reported to security@6membership.com.

Personal-data breach questions, privacy complaints and data-subject requests may be sent to privacy@6membership.com.

Application references, secure-link issues, guardian-access problems and application-record concerns may be sent to applications@6membership.com.

Approved-member access, cards, certificates, status and recovery questions may be sent to admin@6membership.com.

An affected person may use the internal complaint process and retains any mandatory right to contact the Nigeria Data Protection Commission, a consumer authority, financial institution, court, law-enforcement body or another competent authority.

This Policy may be updated to reflect new systems, providers, access methods, threats, legal obligations and incident procedures.

A material update will be handled under the central policy-update framework.