Security and trust information for Reign.
See how Reign is deployed, how customer environments and data are protected, what independent assurance and control mappings are available, and how to report a vulnerability.
Attestation: iTmethods holds a SOC 2 Type II attestation for Reign Ops. The report, scope and period are available under non-disclosure. What is claimed, and what is not →
Security responsibilities for the selected deployment.
Each statement is tied to the selected deployment and the service in scope.
Reign uses a dedicated single-tenant deployment for each customer. Supported patterns include infrastructure iTmethods operates, the customer’s environment, air-gapped environments and sovereign deployment requirements.
Identity, administrative access, service identities and privileged operations follow the requirements agreed for the customer environment. The deployment record identifies who administers the service and where access activity is recorded.
The deployment record documents data flows, storage, retention, encryption, key responsibility, telemetry and evidence destinations for the selected pattern.
Monitoring, vulnerability management, change control, incident response, backup and recovery are defined for the service in scope, with named ownership and escalation routes.
Security evidence available for review.
Sensitive material is provided through the appropriate protected channel.
Depending on the service and deployment in scope, iTmethods can provide the Reign Ops SOC 2 Type II report, architecture and data-flow information, the current subprocessor list, access and change-control information, and relevant operating evidence.
What the standard pack contains
A current list of subprocessors, with advance notice of changes.
The list is maintained. It is released with the pack and kept current after signature.
The list
We maintain a list of the subprocessors involved in operating a customer instance, with the category of processing each one performs and the region in which it performs it. The list is released under non-disclosure as part of the standard pack and is not published on this page. No vendor is named here.
Notice of change
Changes to the list are notified in writing to the contacts a customer nominates for this purpose, in advance of the change taking effect, with the reason for the change and the category of processing affected. Where a customer holds an objection right under the agreement, the notice states how to exercise it. The mechanism sits in the contract rather than on this page.
Categories of data involved
- Source code and repository metadata belonging to the customer, where the engagement covers build and delivery tooling.
- Pipeline, build and deployment telemetry, including job records, timings and outcomes.
- Identity and access records for the users of the platform, sufficient to authenticate them and to evidence who did what.
- Configuration and policy definitions for the platform itself.
- Support correspondence and any artifacts a customer attaches to it.
Personal data in scope is generally limited to the workplace identity of platform users. Where an engagement puts a wider category in scope, that is recorded in the agreement rather than assumed by us.
What Gateway records at the model boundary.
The selected deployment defines approved model and tool destinations, capture and retention settings, and where evidence is stored. Reign Gateway applies policy before a call reaches an approved destination and records the caller, policy decision, destination and outcome. Content capture is off by default, so Gateway can record the decision without storing the text that triggered it. Calls outside policy are refused and recorded. This is enforcement with evidence, not a guarantee that mistakes are impossible.
Report a security concern.
One address, monitored, with a person behind it.
Report a suspected vulnerability through security@itmethods.com or the published security.txt. Include the affected component or address, steps to reproduce, the likely impact and a way to contact you. Customers should continue to report service incidents through their established escalation route.
What to include
- The affected component or address, and the version if you know it.
- Steps to reproduce, in enough detail that we can follow them.
- The impact you believe the issue has.
- How you would like to be credited, or that you would prefer not to be.
What we do with it
- The report is acknowledged to the address it came from and assigned to an owner.
- It is triaged by engineers who work on the affected component.
- Where a customer instance is affected, the affected customers are notified through the contacts held for that purpose.
- The reporter is told what was concluded, including when the conclusion is that no change is required.
We ask that reporters do not access, modify or retain data belonging to anyone else while testing, and that details are withheld from publication until a fix is available. We do not operate a paid bounty program, and we state no response window here rather than invent one we cannot hold to.
Encryption. Isolation. Evidence.
The architectural choices a reviewer actually asks about, stated without a badge wall.
Encryption in transit and at rest
TLS on the public surface. Encryption at rest on managed infrastructure. Key handling for a given instance is described in the pack, not asserted as a slogan here.
Where are the keys?
Tenant isolation
Every product deploys as a single-tenant dedicated instance, in your own AWS or Azure account or in infrastructure iTmethods operates. Both are available today and both are single-tenant. Google Cloud is planned for 2027. Air-gapped and sovereign deployment are supported. There is no multi-tenant operating model.
Who else is on this instance?
Evidence by design
Identity, policy decisions and change records are produced as the work happens. Reign Ops holds a SOC 2 Type II attestation, released with its scope under non-disclosure; no other certification, authorization or accreditation is claimed. What we publish about our own engineering, and the denominator under it, is on what we measured.
What can you send a reviewer?
Three ways to reach us.
Researchers, procurement and a briefing each have a direct path.
Vulnerability disclosure
RFC 9116 security.txt at /.well-known/security.txt. Email security@itmethods.com.
Attestation and evidence
The SOC 2 Type II report for Reign Ops, with its scope and period, is released on request under non-disclosure. Write to security@itmethods.com or raise it in a briefing.
Ask for the pack.
A working session
Most reviews are shorter when the reviewer talks to the engineers who own the control. Book a briefing and we will put the right people in the room.
Send the questionnaire.
Most security reviews are shorter when the reviewer talks to the engineers who own the control. Write to us and we will put the right people in the room.