Security Statement
What is in place today, what is being built, and what is on the roadmap. We are a young operation and we would rather give you a short list you can verify on a call than a long one you cannot. This page is dated and is updated as controls go in.
Language: this document is published in English. Any translated version is provided for convenience only, the English text is the authoritative version and prevails in the event of any inconsistency.
1. Our posture, stated plainly
Security questionnaires are where outsourcing deals stall, usually because a vendor overstates its position and then cannot evidence it. We would rather tell you exactly where we are.
What we are: a delivery operation in Lahore, contracting through a US commercial entity, running voice sales and customer experience programmes on our own operations platform.
What we do not hold: a SOC 2 report, ISO 27001 certification or an independent penetration test. Each is on the roadmap below, and we will not claim any of them until an auditor or tester has issued it.
2. In place today
Each item below can be shown to you on a call: the signed document, the setting, the log.
- Confidentiality agreement signed by every agent before they touch a client programme, surviving after they leave. Every agent also signs the employee handbook, which carries the data handling rules, and re-signs when it changes.
- Recorded lines with disclosure, paused for sensitive details. Every call opens with a recording disclosure. Agents pause the recording while a customer gives identity or payment details and resume it afterwards, so those details are not captured. Recordings are retained for quality review and dispute resolution.
- No sensitive customer data in our systems. Agents record name, service address, phone and email only. Identity numbers, dates of birth and payment details go directly into the client's or provider's own portal and are never repeated aloud, written down, messaged or kept. This rule is in the call script, the handbook and the agent's signed agreement.
- Role-based access on our operations platform. Each person has an individual login and sees only what their role needs; agents see their own leads, sales and pay, not each other's. Idle sessions are signed out. Login attempts are throttled.
- Two-step verification on the accounts that hold the platform, its data and this website.
- Nightly backups of operational data to a separate, owner-only location, kept for 30 days, with an alert if a backup is missed.
- Floor rules: clean desk, no removable media on company devices, personal phone use restricted at the desk.
- Same-day removal of access when someone leaves.
3. In progress
- Written data handling statement: what we hold, why, for how long and who can see it. Available to any client on request once published.
- Change audit trail on the operations platform: who changed what, and when, for every record.
- Separate credential store for platform logins, apart from operational data.
4. Roadmap
- SOC 2 Type II. Controls first, audit when a client engagement requires it.
- ISO/IEC 27001, on the same basis.
- Independent penetration test of the operations platform, arranged for a specific engagement where a client requires it.
- Background verification on every hire as a documented standard, in addition to reference and identity checks at onboarding.
- HIPAA and GDPR paperwork (Business Associate Agreement, Data Processing Agreement) put in place with the first engagement that needs them.
- Dedicated, access-controlled floor space for regulated programmes.
- Documented business continuity plan with tested recovery, beyond the backups already in place.
5. Certification status
| Framework | Status | Detail |
|---|---|---|
| SOC 2 Type II | Roadmap | No report exists. Controls are being put in place first; audit timing depends on client demand. |
| ISO/IEC 27001 | Roadmap | Not certified. Same basis as SOC 2. |
| GDPR / UK GDPR | On request | No EU or UK personal data is processed today. A Data Processing Agreement is put in place with the first engagement that needs one. |
| HIPAA | On request | No protected health information is processed today. A Business Associate Agreement and PHI training precede any healthcare engagement. |
| PCI DSS | Out of scope by design | We do not store, process or transmit cardholder data in our own systems. Where a customer gives payment details, they are entered directly into the client's or provider's portal. The recording is paused while they are given (section 2). |
6. How client and customer data is handled
- Data minimisation: we ask for, and record, the narrowest data set that lets us deliver the service.
- Agents work inside the client's own systems under the client's licences and access controls wherever the client prefers, so the client's data stays in the client's environment.
- Data held in our own platform is encrypted in transit and at rest by the platform provider.
- Retention: where an engagement does not specify a period, client data is kept for the duration of the engagement and returned or deleted within 30 days of termination. Call recordings follow the client's requirement, or 12 months by default.
- Client programmes are kept separate in our platform; an agent on one programme cannot see another.
7. AI systems
- Client data is not used to train third-party foundation models.
- AI-generated output in regulated or high-impact contexts is subject to human review or escalation.
- Every AI-supported workflow, and every AI-delivered language, is documented in the SOW.
8. Incident response
If we confirm a security incident or personal data breach affecting a client, we notify that client without undue delay and within any period specified in the applicable agreement, tell them what we know and what we are doing about it, and support them in meeting their own regulatory notification obligations. A written incident procedure is part of the in-progress work in section 3.
9. What we ask of clients
Security is shared. We ask clients to provision access on a least-privilege basis, to notify us promptly of leavers on their side, to keep any DPAs and BAAs current, and to tell us in advance when a programme's data classification changes.
10. Reporting a vulnerability
If you believe you have found a security vulnerability in this website or in any system we operate, please report it to Info@premiercore.solutions with "Security" in the subject line.
Please give us a reasonable opportunity to investigate and remediate before public disclosure. We will acknowledge your report and keep you updated. We will not pursue action against researchers who act in good faith, avoid privacy violations and service disruption, and do not access or modify data beyond what is needed to demonstrate the issue.