How we handle data

One

Who is accountable for your data, and who is accountable for ours

The DPDP framework distinguishes two roles, and a security integrator sits in both. Most do not say which.

What that means in practice

We hold no client footage.

Not on a laptop, not on a drive, not in an office archive, not temporarily. Where a clip is needed it is exported by you, on your system, and it stays with you.

We do not administer systems holding your staff records.

Access control databases containing employee names, photographs and credentials remain yours to administer.

Viewing happens on your site, in your building.

An engineer looks at a system in front of him, in your premises, as part of diagnosing a fault.

We hold no remote credentials to any client system.

Where remote support is needed, your employee opens the session, chooses when it opens, and stays present for it. The access ends when they close it. There is no saved connection at our end and no way for us to connect without you.

Every remote session produces a service report.

When it happened, what fault it addressed, and who was present.

This is company policy rather than preference, and it predates the DPDP framework. It is also why we can state plainly what we do and do not hold: a claim only worth making if it is enforced rather than intended.

Two

Who can see your footage

Nobody at Concept, unaccompanied.

We do not hold logins to your system.

When an engineer works on your recording or access system, it is your team member who is logged in. Our engineer is beside them, troubleshooting and guiding.

Nothing happens unattended.

There is no circumstance in which our engineer is alone with your footage, on site or remotely.

The account in your audit log is your own.

If you ask who viewed your footage on a given date, your system answers with your employee’s name: because that is who was logged in.

Logging is configured to your requirement, not ours.

What your system records, and for how long, is your decision. We implement what you specify and we tell you what the platform is capable of.

Why this is the position

An integrator holding standing credentials to a client’s recording system is common, and it creates a problem neither party usually names: the client’s audit log contains a shared account belonging to a company rather than a person, and the client cannot say who was behind it.

We would rather not be in that log at all.

Three

How long we keep things

Our own CCTV: 30 days, verified.

Our office recording holds thirty days, and it is checked against real recording rather than read off a configuration screen. It is the same test we run on your system during an assessment, and we would not ask you to meet a standard we do not.

Service reports and site records: retained for the life of the maintenance relationship, and for a defined period afterwards.

These are the record of what was installed, what was found and what was changed. A client returning after two years should not have to rebuild that history from memory, and neither should we.

Client and enquiry contact details: 24 months from last contact.

The same period our privacy policy sets out, applied to enquiries and lapsed relationships alike. One number, one rule, one place it is written down.

Employee records: what statute requires, and no longer.

Payroll, tax and provident fund records carry their own statutory retention periods. What falls outside them is not kept indefinitely.

What we do not do

We do not keep footage until a disk fills, and we do not treat “we have storage” as a retention policy. A retention period is a decision. Where nobody has made it, the answer is whatever the hardware happened to do.

Four

When somebody leaves

Same day. Not same week.

Email, systems and devices are withdrawn with immediate effect on the day a person leaves, against a checklist rather than against whoever happens to be handling it. The checklist is worked through and the record is kept.

There is nothing standing at your site to revoke.

Site access is not a pass an engineer holds. Every attendance is authorised individually: raised internally, approved by our operations and by a director, then sent to your administrator for approval before the day.

Which means a person who leaves us cannot attend your site the following week.

Not because we remembered to cancel something, but because there was never a standing permission to cancel.

Why it is built this way

The common arrangement is a contractor’s pass issued once and valid until somebody thinks to withdraw it. It works until the day it does not, and the failure is silent. Nobody notices a pass that should have been cancelled until it is used.

We would rather ask you for approval every time than hold something that outlives the reason it was issued.

Five

If something goes wrong

There is a name, not a queue.

A client reporting a suspected breach reaches Anagha at the service desk, who escalates to a director immediately. Response is deployed according to the cover in place. There is no ticket system to wait behind.

The clock is known.

The DPDP Rules require the Data Protection Board to be notified on discovery of a personal data breach, and affected individuals within 72 hours. Our team knows those obligations. A breach is not the moment to find out what the timeline is.

It is written down.

Who is called, in what order, and what is done. A documented list of actions rather than a plan somebody remembers under pressure.

Our own systems are held to the same standard.

Where a breach affected data we hold ourselves, a director decides the response and makes the calls personally. Clients hear it from us, and they hear it early.