Summary

  • Thomas Processing & Systems S.A.S. identifies itself as a Colombian member of Grupo Thomas Greg & Sons that administers technology platforms and advertises infrastructure, software and outsourcing services.
  • LACNIC records the exact legal name as the holder of AS266868, 45.239.115.0/24 and 2803:caa0::/32, giving the company a verifiable Internet-number-resource identity.
  • RIPEstat observed the IPv4 /24 announced on 22 July 2026 with broad collector visibility, while the registered IPv6 /32 was not observed as announced in that snapshot.
  • The phrase Operacion y Monitoreo de Datacenter appears in a company service presentation, but it does not establish ownership or control of a named data centre, rack estate, power system, cooling plant or fibre route.
  • The central accountability question is therefore not whether TPS advertises managed infrastructure, but which party controls each physical, contractual and recovery layer beneath the advertised service.

A service company appears before an asset owner

Thomas Processing & Systems S.A.S. enters the public record in two different ways. Its own documents describe a Colombian technology company inside Grupo Thomas Greg & Sons, with a portfolio spanning infrastructure, software and business-technology support. Internet registry records separately identify the same legal name as the holder of an autonomous system and address resources. The two views overlap around a technology operator, but they answer different questions.

The corporate view explains what TPS says it does. The registry view shows which Internet-number resources are registered to it. Neither view is an inventory of buildings, servers, racks, power feeds, cooling systems, fibre paths or customer contracts. That distinction is especially important because managed infrastructure can be delivered through assets owned by the provider, assets leased from another operator, public cloud platforms, customer-owned equipment, group-company systems or a mixture of all four.

The strongest legal identity anchor is the company's privacy policy. It names Thomas Processing & Systems S.A.S., gives NIT 900.966.568-1, places the company in Colombia and describes it as part of Grupo Thomas Greg & Sons. The document says TPS administers and monitors the group's technology platform and handles data-processing activities including transmission, digitisation, verification and storage for companies in the group and for external customers.

That wording establishes an operating role more clearly than a generic company directory entry could. It indicates that TPS is presented as a service organisation rather than merely a dormant resource holder. It also introduces a responsibility question: platform administration and data processing can involve applications, infrastructure, identity, storage, communications and recovery, yet the policy does not divide those responsibilities among TPS, group companies, customers and any third-party hosts.

The policy lists business addresses in Bogota and Barranquilla. Those locations help identify and contact the company. They are not evidence that either address contains a data centre, a network point of presence, a rack hall or company-owned technical plant. A registered office, correspondence address or operating office can support an infrastructure service without housing the underlying compute and network assets.

This creates a useful starting boundary. TPS can be described as a Colombian managed-technology and cloud-service company because that description follows its own service materials and legal identity record. It cannot be described as a data-centre owner or physical infrastructure operator because the available records do not identify the relevant facilities, assets or control rights.

TPS is therefore most visible as an organiser and administrator of technology services. The public evidence provides a real legal identity, a stated group role, a service catalogue and a registered routing identity. It leaves the physical delivery chain open. That gap is the defining fact of the company's current infrastructure profile.

The group relationship defines context, not complete control

Grupo Thomas Greg & Sons gives TPS an important institutional setting. The privacy policy says TPS belongs to the group, while the 2025 corporate presentation traces the company to the group's technology area and to Data Processing and Systems in Barranquilla. The presentation says the business emerged in 2016 and designs secure, customised technology solutions in Colombia for group clients.

This history suggests that TPS grew from an internal technology function into a named operating company. Such a path is common in large business groups: an internal team standardises platforms, builds specialist expertise and then offers services across affiliates or to external customers. It can produce economies of scale and consistent governance. It can also make responsibility harder to read from public materials because the service company, asset owner and consuming business may sit under the same corporate umbrella.

The group relationship does not prove that TPS owns every system it administers. A group technology company can operate equipment booked to another affiliate, manage cloud accounts held by a parent, support customer-owned servers or coordinate third-party suppliers. The available documents do not state how assets are allocated across the group, how costs are charged, or which entity signs facility and connectivity contracts.

The privacy policy's reference to group companies and external customers widens the possible operating surface. It indicates that TPS's data-processing role is not described as exclusively internal. It does not quantify the split. There is no accepted revenue breakdown, customer list, contract sample or workload inventory showing how much activity comes from affiliates and how much comes from unrelated organisations.

That missing split matters because internal and external service models can create different accountability structures. Within a group, governance may rely on shared policies, internal service agreements and common ownership. External customers may depend on negotiated service levels, audit rights, data-processing terms and exit arrangements. The public material does not show whether TPS uses the same technical stack or responsibility model for both.

The group name also should not be used to import claims from unrelated affiliates into TPS. A capability held somewhere in Grupo Thomas Greg & Sons is not automatically a TPS asset or service. A customer relationship involving another group company is not evidence that TPS supplies the technology layer. The legal and operational link must be shown directly before it becomes part of the TPS account.

For infrastructure readers, the group relationship is most useful as a prompt for better questions. Which entity owns the production assets? Which signs cloud and carrier contracts? Which entity is responsible for disaster recovery? Which one communicates with customers during an incident? The current documents establish the family relationship but do not publish those answers.

The service catalogue is broad, but it is not an asset register

TPS's 2025 presentation describes a portfolio that combines technology-infrastructure administration with software analysis, design and development, IT governance, project management and service management. It advertises infrastructure as a service, software as a service, custom software and business-technology outsourcing. This is a broad managed-service proposition rather than a narrow connectivity product.

Under infrastructure as a service, the presentation refers to processing, storage, networks and support. It also describes usage-based charging, platform administration, backup and restoration, logical security, server supply and administration, telephony and technical support. These are functions that can sit across on-premises equipment, leased infrastructure, hosted private platforms and public cloud services.

The catalogue is useful evidence of what TPS wants customers and group companies to understand about its capabilities. It shows that the company presents itself as responsible for more than application development. It places infrastructure operations, continuity functions and network administration inside the advertised service boundary.

It does not show which capabilities are active for which customers. A corporate presentation can cover services available in principle, services delivered through partners, services used mainly inside a group, and services supplied only under particular contracts. Without customer agreements, current product documentation or independently corroborated deployments, the catalogue cannot be converted into a claim that every listed function is presently delivered at scale.

The same limitation applies to asset ownership. Processing can run on customer hardware, group hardware, leased servers or cloud instances. Storage can refer to local arrays, cloud object storage, backup appliances or managed access to another provider's systems. Network administration can cover logical configuration without ownership of the circuits or routers. Server supply can involve procurement and management rather than ownership of a standing server estate.

Backup and restoration language introduces continuity responsibility without defining the recovery boundary. A provider can administer backup jobs while storage is supplied elsewhere. It can manage restoration procedures while the customer controls application validation. It can monitor successful jobs without controlling power, physical media or upstream connectivity. The public materials do not say where TPS's responsibility starts and ends.

Logical security also needs careful treatment. The phrase can cover access control, configuration, monitoring, patching, segmentation or incident handling. It does not prove a certification, a successful control environment or a particular security outcome. The current record contains company-originated capability language, not an independent audit of implementation or performance.

The service catalogue therefore supports a cloud-service and managed-infrastructure classification. It does not support a physical-asset profile. Its value lies in identifying the layers TPS says it can manage and the accountability questions that follow from each one.

Data-centre operation is a service phrase, not proof of a facility

The most easily overstated phrase in the presentation is Operacion y Monitoreo de Datacenter, or data-centre operation and monitoring. Read in a service catalogue, it signals that TPS advertises operational work associated with a data-centre environment. It does not identify the site where that work occurs or the legal rights TPS holds over the site.

Data-centre operation can describe several arrangements. A company may own and operate a facility. It may operate equipment inside a leased colocation suite. It may monitor a customer's room. It may administer systems hosted by a group affiliate. It may provide remote operational support while a specialist landlord controls the building, power, cooling and physical security. The phrase alone does not choose among those models.

Facility ownership would require site-level evidence. Useful records could include a named address tied to technical use, land or lease documentation, permits, utility arrangements, construction disclosures, equipment inventories, certifications with a defined scope, or a direct company statement specifying ownership and operational control. None of those appears in the available public records.

Capacity claims would need a different layer of proof. Rack counts, commissioned power, available power, floor area, cooling design, occupancy, interconnection inventory and customer deployments cannot be inferred from a service list. Nor can Tier level, uptime, redundancy or recovery performance be derived from the word monitoring.

The company's Bogota and Barranquilla addresses do not close the gap. They are legitimate identity and contact details. They do not say that servers or network equipment are located there. Office addresses frequently appear in privacy policies because data subjects need a contact point; that administrative purpose is different from documenting critical infrastructure.

The boundary also protects against a common visual error. A generic photograph of racks or an operations room could easily be mistaken for a TPS facility if presented without a caveat. No image has yet been bound to this account, and any later illustration would need to remain explicitly generic and non-documentary. It could communicate managed-service responsibility without implying that the depicted equipment belongs to TPS.

Treating the phrase as a service claim rather than an ownership claim does not diminish its importance. Operating and monitoring a data-centre environment can create substantial responsibility even without property ownership. The operator may control alerts, changes, access procedures, backup tasks and incident escalation. The key question is which of those responsibilities TPS actually holds under its contracts.

The present record does not answer that question at customer level. It establishes that TPS advertises the function. It does not identify a named facility, a named customer, an installed asset base or a measurable operating result. The responsible description is therefore managed data-centre operations as a company-stated capability, not ownership or control of a TPS data centre.

LACNIC gives TPS a verifiable network-resource identity

The independent infrastructure record becomes firmer at LACNIC. RDAP identifies CO-TPSS1-LACNIC under the exact legal name THOMAS PROCESSING & SYSTEMS S.A.S. The registrant is associated with AS266868, the IPv4 block 45.239.115.0/24 and the IPv6 block 2803:caa0::/32.

The autonomous system was registered on 27 July 2018. That date places the resource identity after the 2016 origin described in the corporate presentation. It does not reveal why the AS was obtained, which services use it, or whether the same operating model has remained in place since registration.

The IPv4 allocation contains 256 addresses. The IPv6 /32 is far larger in address terms, as IPv6 allocations are designed to support hierarchical assignment rather than direct comparison with IPv4 counts. Registration gives TPS a public administrative relationship to both blocks. It does not show how addresses are assigned internally or to customers.

RDAP also provides administrative, technical and abuse-contact surfaces associated with a thomasps.com domain and a Barranquilla registrant address. Those details help other networks and registry users identify a responsible contact. They do not prove that the domain is a current public product website or that the address hosts routing equipment.

An autonomous system number is an identifier for routing policy on the public Internet. Holding an ASN can be relevant to a managed infrastructure provider because it creates the option to originate address space and manage external routing relationships. It does not automatically make the holder a retail ISP, a transit carrier, a regional access network or a facilities operator.

The resource records are valuable because they give the service catalogue a checkable infrastructure surface. TPS is not visible only through marketing language. It has a named ASN and registered address space that can be compared with routing observations. That makes questions about route control, contact accuracy and address use more concrete.

The records remain administrative. They do not disclose router ownership, circuit contracts, interconnection sites, route-filtering policy, customer assignments or network staff. A registered prefix can be announced from equipment owned by the holder, equipment managed by a contractor or infrastructure supplied by another provider.

For customers, the resource identity could matter in several ways. It may support stable addressing, direct routing control or separation from a host's address space. It could also be used for a limited platform rather than the whole service portfolio. The available sources do not connect the ASN to a named product, customer or workload.

The safest conclusion is precise: TPS is the active LACNIC registrant for AS266868 and the named IPv4 and IPv6 resources. That is evidence of Internet-number-resource control. It is not evidence of facility ownership, national coverage, customer scale or physical network independence.

The dated routing view shows IPv4 visibility, not the whole platform

RIPEstat provides a dated view of AS266868 on 22 July 2026. Its overview marks the autonomous system as announced. The announced-prefix and routing-status data show 45.239.115.0/24 visible as an IPv4 origin during the accepted observation window.

The routing-status view reports one IPv4 prefix and 256 announced IPv4 addresses. It records visibility at all 327 reporting IPv4 RIS peers in the snapshot. Broad collector visibility means the route was observable across that measurement surface. It does not measure end-user reachability from every network or guarantee that traffic could reach every service behind the prefix.

No IPv6 announcement was observed in the accepted snapshot, despite the registered 2803:caa0::/32 allocation. Registration and announcement are separate facts. TPS can be described as holding the IPv6 resource, but not as visibly operating dual stack through that block at the dated observation.

The lack of an observed IPv6 route is not proof that TPS has no IPv6 activity anywhere. Private environments, customer-specific deployments, unobserved routes or later changes could exist. The record supports only the narrower statement that RIPEstat did not observe the registered /32 as announced in the selected public view.

The route table also does not reveal the application estate. A single /24 could support public services, management endpoints, customer systems, group workloads, network infrastructure or a mixture. Prefix visibility cannot identify the servers, storage, software or business processes using the addresses.

Full visibility among the reporting IPv4 RIS peers should not be converted into a quality score. Route collectors indicate propagation of routing information, not latency, packet loss, throughput, security posture, backup status or recovery readiness. A widely visible route can still lead to a concentrated physical path or a fragile service stack.

The date must remain attached to the observation. Routing changes as networks alter policy, providers, equipment and address use. AS266868's public surface on 22 July 2026 is a useful measurement point, not a permanent description of the company's network.

This measured view narrows the infrastructure story. TPS has one clearly visible IPv4 prefix behind its ASN and a registered IPv6 allocation that was not visible in the same way. That is enough to discuss routing accountability. It is not enough to map the managed cloud platform.

AS3549 is a logical observation, not a supplier disclosure

RIPEstat's neighbour data places AS3549 on the left side of the observed IPv4 path surface for AS266868. This is a routing observation. It shows that collector paths contained a relationship in the measured data. It does not disclose the legal or commercial agreement behind that appearance.

AS-path adjacency can arise from several arrangements. The neighbour could be a transit provider, a peer, a customer, an intermediary visible through a particular collection method, or part of a routing arrangement whose commercial classification is not public. The endpoint's left-side label is not a contract.

The observation also does not prove exclusivity. One visible neighbour in a selected data view may reflect the active path set seen by collectors, while backup arrangements, private interconnections or later changes remain outside the snapshot. Conversely, the presence of more than one logical neighbour would not by itself prove physical diversity.

Physical path claims require site and circuit evidence. Two routes can share the same building entrance, duct, metro ring, power environment or carrier facility. A single logical relationship can sometimes be delivered through diverse physical infrastructure. BGP data alone does not reveal that layer.

Calling AS3549 a commercial upstream would therefore go beyond the accepted evidence. So would describing it as an independent exit, a sole dependency or a physically diverse path. Those characterisations require operator confirmation, routing-policy documentation, contract evidence or a more complete measurement and topology record.

The useful fact is narrower. AS266868 was not observed in isolation; its public route appeared through an AS-path environment that included AS3549. That gives network engineers a concrete identifier for further inquiry. It does not settle who buys service from whom.

For continuity analysis, the missing commercial classification matters. If TPS depends on one external relationship for public reachability, that could create concentration. If several arrangements exist but only one appears publicly, the route view may understate diversity. The current evidence cannot distinguish those cases.

The correct treatment is to preserve AS3549 as a dated logical neighbour observation. It can anchor a question about routing dependency, filtering and escalation. It cannot anchor a claim about supplier identity, contract structure or physical redundancy.

Managed cloud services distribute responsibility across layers

TPS's service catalogue spans compute, storage, networks, software, backup, security and support. Each layer can be managed by one party and physically supplied by another. The resulting service may feel integrated to a customer even though operational responsibility is distributed across several contracts and asset owners.

At the compute layer, TPS could administer operating systems, virtual machines or application platforms without owning the host servers. It could supply servers directly, procure them for a customer or manage equipment held by a group company. The presentation does not specify which model applies.

At the storage layer, responsibility can be divided among capacity provision, access control, replication, backup scheduling, retention and restoration. A provider may manage policy while another party owns the disks or cloud service. The public documents do not identify the storage architecture or custody model behind TPS's claims.

The network layer has the clearest independent trace because AS266868 and 45.239.115.0/24 are visible. Even there, resource registration and route origin do not reveal the circuits, routers, interconnection sites or field support. Logical routing control is one component of network service, not the whole physical path.

Backup and restoration create a particularly important handoff. Successful backup jobs do not guarantee recoverability. Recovery depends on valid data, available infrastructure, credentials, network access, application sequencing, testing and business approval. TPS advertises backup and restoration, but the current sources do not describe recovery objectives, test results or customer-specific responsibility.

Logical security is also shared. TPS may administer controls while customers own identity policy, vendors supply platforms and facility operators control physical access. A general security capability statement cannot show which controls apply to a particular workload or whether they operated successfully during an incident.

Support and telephony add dependencies outside the server environment. A service desk can coordinate incidents without owning the failed component. Telephony can rely on external carriers and customer access. The catalogue shows that TPS aims to manage these interfaces, but it does not publish the supplier and escalation map.

This distributed model explains why the asset gap matters. A customer assessing continuity needs to know not only that TPS manages a service, but which party can repair each layer, which contract governs restoration and which dependencies are shared across customers. The public record does not provide that full chain.

The company can still be important without owning every asset. Managed-service value often comes from coordination, governance, specialist staff and operational discipline. The evidence supports that as TPS's advertised role. It simply does not permit the coordination role to be mistaken for physical ownership.

Customer dependence is described broadly and measured poorly

The privacy policy refers to technology and data-processing services for companies in Grupo Thomas Greg & Sons and external customers. This establishes that TPS describes a customer surface wider than one internal department. It does not identify those customers or quantify their dependence.

No available public record lists active customer contracts, workload counts, user numbers, revenue concentration or critical public services running through TPS. Without those links, the social and economic consequences of a TPS disruption cannot be assigned to named organisations or communities.

The distinction between group and external customers could affect concentration risk. Heavy reliance on one corporate group may create correlated operational dependencies across affiliates. A broader external portfolio may create different support and isolation requirements. The current records do not disclose the mix.

The registered /24 should not be treated as a customer census. Address counts do not map directly to customers, users, servers or services. Network address translation, private addressing, virtual hosting, cloud connections and shared platforms all break simple arithmetic between addresses and business scale.

Routing visibility likewise cannot measure customer dependence. A route can be visible while an application is unavailable. An application can depend on private links that do not appear in the public route view. Collector data helps establish network presence, not business impact.

Public procurement records, customer disclosures, service notices or contract summaries could strengthen the dependency analysis if they name TPS and match the exact legal entity. None of those appears in the available public records. No customer relationship should be inferred from the broader group's activities.

For now, the customer statement remains company-originated and general. TPS says it serves group companies and external customers. The scale, identity and criticality of those customers remain undisclosed. That is enough to make continuity questions relevant, but not enough to quantify impact.

Offices identify the company without locating its infrastructure

The privacy policy and registry material contain addresses in Bogota and Barranquilla. These details help close the legal identity boundary. They show where the company can be contacted and how records have associated it with Colombian locations at different dates.

They do not establish the location of servers, storage, network handoffs or managed workloads. A company can administer infrastructure from an office while the equipment sits in a customer facility, a colocation site, a group data centre or a public cloud region.

It also should not be used to infer network geography. The Barranquilla registrant address does not prove that AS266868 originates there. The Bogota headquarters reference does not prove that the /24 serves Bogota. Public BGP data in the accepted set does not locate the routers or endpoints at building level.

Facility claims require a direct bridge between an address and technical use. A permit, lease, facility listing, engineering document, utility record or explicit company disclosure could provide that bridge. An administrative contact record does not.

The same rule applies to images. A future generic operations illustration cannot be captioned as a TPS office or data centre. Without a verified site photograph and provenance, the image must remain conceptual. Visual specificity should not outrun documentary specificity.

The addresses are still useful. They distinguish the Colombian legal entity, support contactability and align the company with the group narrative. They just serve an identity purpose rather than an asset-mapping purpose.

This separation keeps the operating account accurate. TPS has a Colombian corporate presence and a registered network-resource identity. The physical locations and ownership arrangements behind its service delivery remain unproved.

Recovery claims require more than backup language

Backup and restoration appear in TPS's advertised infrastructure services. These are important capabilities because managed platforms are judged not only by daily operation but by their ability to recover from deletion, corruption, equipment failure, software error and wider disruption.

The presence of the words does not establish a recovery result. A credible recovery account would need defined recovery-time and recovery-point objectives, tested procedures, evidence of successful restoration, clear responsibility for application validation and disclosure of dependencies that could block recovery.

Storage location matters. Backups held in the same failure domain as production can be vulnerable to common events. Copies in another environment can improve separation, but only if credentials, connectivity and restoration capacity remain available. The current materials do not describe the architecture.

Operational authority matters as well. TPS may schedule and monitor backups while a customer approves restoration. A cloud provider may control the underlying snapshot system. A group security team may control keys. A facility operator may control access to hardware. Recovery depends on all of those handoffs.

Network availability can become a recovery constraint. AS266868 provides a public routing surface, but the sources do not connect it to backup traffic or recovery access. They do not show alternate connectivity, out-of-band management or the path by which staff would reach systems during a failure.

Power and cooling remain outside the record. If TPS relies on physical infrastructure, the availability of that infrastructure depends on systems the service presentation does not describe. No claim about generators, UPS capacity, cooling redundancy or facility fire protection can be made.

The absence of these details is not proof of weak practice. Many recovery controls are confidential or customer-specific. It means only that the public record cannot independently verify the strength, scope or results of the advertised capability.

For customers and group companies, the practical question is contractual: what exactly does TPS promise to restore, within what time, using which copies, and who is responsible for each dependency? The current service catalogue makes that question necessary without supplying the answer.

Service governance may be the company's most important control surface

TPS presents IT governance, project management and service management alongside infrastructure and software capabilities. Those disciplines can be central in a distributed delivery model because they define how changes, incidents, suppliers and customer responsibilities are coordinated.

Governance can turn a collection of third-party assets into a coherent service. It can establish approval paths, security responsibilities, monitoring thresholds, escalation rules and recovery priorities. That coordinating function may matter more to a customer than direct ownership of every server or circuit.

The public presentation, however, does not publish the governance framework in enough detail to assess it. There is no accepted control matrix, service catalogue with responsibility assignments, incident process, audit result or customer-specific service-level record.

Project and service management claims should therefore be treated as advertised capabilities. They support the view that TPS positions itself as an integrator and operator. They do not prove response times, change success, customer satisfaction or compliance outcomes.

Network-resource control fits inside this governance question. Someone must maintain LACNIC contacts, manage route origination, coordinate with the observed path environment and respond to abuse or routing incidents. The exact division between TPS staff and external providers is not public.

Software development adds another control surface. Custom applications can create dependencies on source code, deployment pipelines, databases and specialist knowledge. The current sources do not describe code ownership, escrow, deployment rights or how software recovery aligns with infrastructure recovery.

IT governance also shapes how group and external customers are separated. Shared operations can create efficiencies, but customers need confidence that access, data, changes and incidents are appropriately isolated. The privacy policy and presentation establish that data processing occurs; they do not provide an independent assessment of segregation controls.

The governance proposition is therefore plausible and relevant, but not measurable from the current record. It explains how TPS may create value across infrastructure it does not own. It also marks the point where customers need contractual and audit evidence rather than a service list.

What buyers, peers and registries can verify today

Several facts are directly checkable. The legal name and NIT appear in the privacy policy. The group relationship and managed-service portfolio appear in company materials. LACNIC records the exact legal name, registrant handle, ASN and address resources. RIPEstat records a dated public routing view.

These facts support due diligence at the identity and resource layers. A buyer can confirm that it is dealing with the named Colombian company rather than a namesake. A network peer can identify the ASN and registered contacts. A researcher can compare the registered /24 with observed route origin.

The public route view also permits continuing observation. Changes in origin, prefix visibility, IPv6 announcement or neighbour patterns could be tracked over time. Such changes would still need interpretation and should not be labelled as outages or commercial changes without corroboration.

Registry contacts create an accountability channel. Administrative, technical and abuse records give other parties a place to direct questions. The existence of a contact does not prove responsiveness, but it is more useful than an unanchored brand name.

Company documents provide a checklist for contractual verification. If TPS offers processing, storage, networks, backup, security and server administration, a buyer can ask which assets support each service, which party owns them, where data is processed, how recovery is tested and which service levels apply.

What cannot be verified publicly is equally clear. The accepted records do not identify a TPS-owned facility, server estate, fibre route, carrier contract, installed capacity, power system, cooling system, customer deployment or tested recovery result.

The public record also does not establish independent certification. Company-originated language about security, reliability, scalability or savings should remain attributed. A certificate would need a current issuer, scope, legal entity and covered service before it could support a stronger claim.

This division between verifiable and undisclosed facts is useful for procurement. It prevents a buyer from assuming that a broad service label includes physical ownership or a particular resilience design. It also gives TPS a clear route to strengthen disclosure without exposing sensitive topology.

Evidence that would change the operating picture

A named facility record would materially change the analysis. A direct TPS disclosure, lease, permit, certification or reputable facility listing could show where technical operations occur and which entity controls the site. It would need to distinguish office presence from data-centre use.

An asset and responsibility statement would be equally valuable. TPS could explain which compute, storage and network components it owns, which it leases, which belong to customers and which are supplied by group or cloud partners. A simple responsibility matrix could clarify more than a long product catalogue.

Network evidence could close the AS3549 boundary. Routing-policy documentation, operator confirmation, IRR or RPKI context, interconnection records and a dated topology statement could help classify external relationships. Physical diversity would still need circuit and site evidence beyond BGP adjacency.

IPv6 evidence could show whether the registered /32 is deployed. A visible route, operator documentation or customer configuration tied to the exact resource would support a current deployment claim. Until then, allocation and announcement remain separate.

Recovery evidence could include defined objectives, test summaries, architecture boundaries and independent audit scope. It would not need to disclose sensitive configurations. It would need to show which services were tested, which failure domains were separated and which entity accepted the result.

Customer or procurement records could establish dependency. A public contract, customer disclosure or service notice naming the exact legal entity could show where TPS sits in a business process. Such evidence should not be inferred from the wider group's relationships.

Current product documentation could clarify whether the 2025 service catalogue remains active, how services are packaged and whether external customers receive the same operating model as group companies. Pricing, service descriptions and responsibility boundaries would make the cloud-service classification more concrete.

Each of these additions would answer a different question. Facility evidence would address physical location. Asset records would address ownership. Network records would address routing relationships. Contract and recovery records would address customer risk. None can substitute for all the others.

A visible ASN makes the accountability boundary sharper

AS266868 gives TPS a durable public infrastructure identifier. The company can be found in a regional Internet registry, associated with exact address resources and observed in the public routing system. That is a stronger accountability surface than a generic claim to provide cloud services.

The ASN does not make the company a carrier or regional ISP. It shows that TPS has a routing identity associated with its own resources. In a managed-service context, that identity may support platforms, group systems, customer services or operational connectivity. The current record does not allocate those uses.

The one visible IPv4 /24 creates a narrow point of observation. It can be monitored for origin and visibility. It can be associated with registered contacts. It can support incident and abuse escalation. It cannot reveal the full compute estate or the physical path to users.

The registered but unobserved IPv6 /32 adds another accountability question. Resource holders may acquire IPv6 space before public deployment, use it selectively or leave it dormant. The dated snapshot supports no claim beyond registration and the absence of an observed announcement.

The observed AS3549 adjacency adds context without settling dependency. It shows that AS266868 participates in a wider routing environment. It does not publish the contract, topology or redundancy behind that environment.

Together, these facts sharpen the difference between logical control and physical control. TPS is named for the ASN and address blocks. It may originate the route and manage services. The buildings, circuits, hardware and recovery systems remain outside the accepted public record.

That difference is the core of managed cloud accountability. Customers often buy an outcome from one service provider while several infrastructure owners contribute to delivery. The provider's responsibility depends on governance, contracts and operational authority, not simply on whose logo appears on the invoice.

TPS's current public record establishes enough to ask precise questions. It does not establish enough to answer them on the company's behalf. The visible routing identity makes the operating boundary more important, not less.

The safe conclusion is a managed-service boundary, not a facility profile

Thomas Processing & Systems has a coherent public identity. Its privacy policy names the Colombian legal company and its place in Grupo Thomas Greg & Sons. Its presentation describes a managed portfolio covering infrastructure, software, governance and outsourcing. LACNIC ties the exact name to AS266868 and two address allocations.

RIPEstat adds a dated operating signal. The IPv4 /24 was visible through the ASN on 22 July 2026, while the registered IPv6 /32 was not observed as announced. AS3549 appeared as one logical neighbour in the measured path environment.

Those facts justify infrastructure scrutiny. They show that TPS is not merely a software brand with no public network trace. They also stop well before a physical infrastructure dossier. No named data centre, rack inventory, power system, cooling design, fibre route, server estate or carrier contract is established.

The company-stated data-centre operation and monitoring capability should therefore remain a managed-service claim. It may involve substantial operational responsibility. It does not prove site ownership, capacity, resilience or control of every underlying asset.

The customer boundary remains similarly open. TPS says it serves group companies and external customers, but the record does not identify deployments, critical workloads or dependency scale. Routing data cannot fill that gap.

The most defensible account is one of layered responsibility. TPS presents itself as the administrator and coordinator of technology services. Internet records show a limited routing identity under its legal name. The physical and contractual systems beneath those services are not publicly mapped.

For buyers, peers and regulators, that creates a clear due-diligence agenda: verify the legal entity, identify the asset owners, classify the routing relationships, define recovery responsibilities and test the handoffs. Each answer should be tied to a current contract, record or measurement rather than inferred from marketing language.

TPS may possess stronger controls and assets than the public record shows. The absence of disclosure is not evidence of absence. It is a limit on what can responsibly be claimed. The company's visible routing identity proves a network-resource surface; its cloud operating boundary still needs proof.

Sources