What the review actually asks for
An accreditation review is not an architecture conversation. The assessor is not judging whether the design is elegant; they are looking for evidence that specific controls exist, are enforced rather than merely documented, and leave a record that can be examined afterwards. The questions are narrow and repetitive. Who can do this. How do you know they are who they say they are. Where is it written down that they did it. Can you show me now.
The cost of that review is almost entirely set by decisions taken months earlier. A control retrofitted under review pressure is a change to a live system, a new test cycle and a re-submission. A control that was designed in is a screen the assessor is shown. The engineering effort is comparable; the schedule is not, and on a fixed delivery date the schedule is the thing that fails first.
So the controls an assessor asks for are built before they are asked for. In ICCS that means three-role RBAC, JWT authentication, a tamper-resistant audit log with CSV export, dormant TOTP MFA and encrypted camera credentials — present in the release, not on a roadmap. What follows is why each of them is shaped the way it is, because the shape is where most of the argument happens.
Three roles, enforced in the request path
Three enforced roles, not nine advisory ones. A role model that mirrors an organisation chart looks thorough and fails in practice: nobody can state what a given role may do, exceptions accumulate, and within a year most accounts hold the permissive one because that was quicker than asking. Three roles can each be described in a sentence, which means they can be assigned correctly by a duty officer who has not read the manual.
Enforcement sits in the request path, not in the interface. A hidden button is not a control. The check runs server-side on every request, so an authenticated session cannot reach an action its role does not carry, whatever the client chooses to send. JWT authentication carries identity into each request, which is what lets the same check — and the same audit entry — apply to the operator console, to the QRT tablet, and to anything calling the API directly.
The QRT interface is the useful test of whether the model holds. It is a PIN-gated tablet with compact alert cards, a read-only live map, a team GPS heartbeat and nearest-drone dispatch: deliberately less than the operator console, on a device that leaves the room. Read-only is enforced at the same layer as everything else, so the constraint is a property of the system rather than of the screen it is drawn on.
Secrets an inspection will look for
Camera credentials are the quiet finding in any video platform. One-click ONVIF discovery makes adding a device easy, and hot-adding one takes about sixty seconds with no restart — which means credentials for every camera on the estate accumulate in one place, quickly. They are encrypted at rest. An assessor will ask where they live and what happens to a database backup carried out of the building on removable media; both answers have to exist before the question does.
The sensor path is treated the same way. Fence, radar, seismic, thermal and acoustic devices arrive over MQTT or a signed webhook onto a unified alert path, and the posture is fail-closed. A device that cannot be authenticated does not get the benefit of the doubt on a perimeter system. Failing closed is occasionally inconvenient during commissioning and never surprising during an incident, which is the correct trade for this class of platform.
None of this is difficult engineering. It is the difference between a system where the security decisions were taken once, deliberately, and one where each was taken by whoever happened to be implementing that integration that week. A review finds the second kind reliably, because inconsistency is far easier to spot than weakness.
The audit log is the deliverable
Of everything in the security domain, the audit log is where the review spends its time. Not whether one exists — whether it records the things that matter, whether it can be altered by the people it records, and whether it can be got out of the system in a form somebody else can examine. A log that only exists inside the application that wrote it is a claim the application makes about itself.
So the log is tamper-resistant, and it exports to CSV. The export is the unglamorous half and the half that gets used: an assessor wants the records in a spreadsheet on their own machine, filtered by date and actor, without an account on the system and without an engineer sitting beside them explaining a query. Making that a supported operation removes an entire category of argument from the review.
The same reasoning, taken further, produced the custody system of record built for a SEBI-regulated trusteeship: an immutable hash-chained event ledger, architected against the evidentiary standard of BSA 2023, so a record’s integrity can be verified independently of the application that stored it. Different sector, identical question — can this history be trusted by someone who has no reason to trust you.
Controls that ship switched off
TOTP MFA is present in ICCS and dormant by default. That sounds like a hedge and is a deliberate decision about who owns the choice. On an air-gapped estate, second-factor enrolment has physical consequences: shared operator stations, shifts that hand over mid-incident, no route to a password-reset email, and a device-loss procedure that has to be written by the people who run the site rather than by us.
Shipping the control dormant means the capability is in the release and auditable as present, while enabling it is a decision the site takes on its own terms, with an enrolment and recovery procedure it can actually operate. The alternative — on by default — reliably produces either a shared secret on a printed sheet beside the console, or a locked-out operator at the worst possible moment. Neither is a security improvement.
It is a distinction worth making explicitly in a review: a control that exists and is not yet enabled is a different finding from a control that does not exist. The first is a configuration item with a date against it. The second is a change request, a build, a test cycle and another submission.
One system, one audit log — and what we do not claim
Detection, sensors, drones, mapping, recording and access control are one system with one audit log. That is an accreditation argument before it is an architecture one. Five integrated vendors mean five authentication models, five logs with five clocks, five upgrade cycles and five parties to convene when a control has to be evidenced end to end. In an accreditation review, five vendors is five arguments.
One system means an event can be followed through a single record: the detection that graded the alert, the operator who acknowledged it, the policy that permitted a dispatch, the drone that flew, the recording that was retained. Reconstructing that across five products is a correlation exercise performed under questioning. Reconstructing it in one log is a query, and it either returns the sequence or it does not.
One thing this posture is not is a certificate. We hold partner status with AWS, Google Cloud and Red Hat, are a Razorpay Technology Partner and sit in NVIDIA Connect; our engineers hold RHCE, RHCSA, RHCA and OpenShift Administration certification. Separately, we have built against the DPDP Act 2023 and DPDP Rules 2025, SEBI CSCRF 2024, the evidentiary standard of BSA 2023, and DSGVO/GDPR on live work. Building against a framework is an engineering posture, not an accreditation, and we will not describe it as one.
Programmes referenced by codename are classified engagements. Capability, engineering and measured outcome are described in full; the client, the installation and the unit are not named anywhere — disclosure policy.