Snapshot 96915
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Skip to main content Trust summary Security responsibilities for the selected deployment. Each statement is tied to the selected deployment and the service in scope. Dedicated customer environments 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 and access 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. Data protection and evidence The deployment record documents data flows, storage, retention, encryption, key responsibility, telemetry and evidence destinations for the selected pattern. Security operations Monitoring, vulnerability management, change control, incident response, backup and recovery are defined for the service in scope, with named ownership and escalation routes. Evidence 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 01Architecture The deployment is a single-tenant dedicated instance. No shared instance is offered, and none is planned. 02Data flow What is read, what is written, what is retained, and where each of those happens. 03Subprocessors The current list, with the category of processing each one performs. 04Access control Joiner and leaver handling, privileged access, and how access is reviewed. 05Change control How a change reaches a customer instance, and what record it leaves. 06Logging and incidents Monitoring and incident handling, including how a customer is notified and by whom. 07The model boundary The boundary and the controls applied at it, covered in more detail further down this page. 08Attestation The SOC 2 Type II report for Reign Ops, with its scope and period, released under non-disclosure rather than asserted publicly. How to ask. Write to security@itmethods.com or raise it in a briefing. Say which entity is asking, which regulator or internal standard is driving the question, and whether a specific questionnaire has to be completed — because completing your form is a different task from sending our pack, and we would rather do the right one first. Subprocessors and data 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. The model boundary 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. Deployment patterns →Reign Gateway → Vulnerability reporting 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. Data practices 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? Reporting and contact 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. Read security.txt → 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. Book a briefing → Next 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. Start a conversationsecurity@itmethods.com