Not even that, just two wires for modem-to-modem.
Or a minimum of 3 wires for a direct RS-232 cable.
There are a number of simple "AT commands" which modems respond to since the 1980's.
These are ASCII text commands sent from the COM port to the modem to control it.
New commands were added over the years as modem capabilities and features were advancing, for instance the early personal modems were "acoustic couplers" where you picked up the standard telephone handpiece and dialed the remote mainframe manually. Using the rotary dial before touch-tone phone service became available. Once the remote modem answered, you heard the tone then snuggled the handpiece into the receptacles for the telephone speaker & microphone to communicate 2-way data with the remote device. Before PC's you would be using a dumb ASCII terminal to either send commands from the com port to the modem, or once connected properly, to send & recieve data from the remote mainframe.
Before electronics were very well miniaturized, modems were still external peripherals which connected to the com port using a correctly wired RS-232 cable, and connected to the landline using a RJ11 modular connector (which replaced the acoustic coupling).
Once autodialing became a thing, the ATD command appeared which was sent from the COM port to the modem, including the user-entered target phone number i.e. ATD18001234567, initiating the sequence which connected to the landline, checked for dial tone, then autodialed 1-800-123-4567.
Originally COM ports were known as "serial" or RS-232 connections on mainframes until people started calling them COM ports when IBM came out with its early PC's. They were originally 25-pin D-sub connectors having male pins, OTOH the parallel LPT printer port was a 25-pin D-sub having female sockets. The com port is serial and never needed more than 9 conductors for its cable (often only 3 conductors) and was soon standardized down to a 9-pin D-sub having male pins. It was expected that all computers would have one or more com ports from then on, since this was the main way they were intended to connect to each other in case people wanted to do that. But most users simply moved files by physically transferring floppy disks instead. COM1 ended up as the default mouse connection once the mouse started to gain traction (the early mice had some real balls), eventually the PS/2 style mouse connection took over that duty after the IBM PS/2 version of the PC pioneered that little dedicated circular connector.
Such floppy transfer over "sneakernet" has some obvious limitations when the remote PC is in another building, or even a different floor of the same building, so those few organizations which had a qualified geek would sometimes run an RS-232 cable in-between the offices which needed to be linked. Then with the right communication software users at either end could transfer ASCII data live from terminal to terminal using their command lines, even whole files or do interactive autocommunication. Nobody had ever heard of a GUI.
If the remote computer was in a different building you could use an RS-232 cable up to a mile or two in length depending on data speed (baud rate):
https://blog.seabird.com/ufaqs/what-is-the-maximum-cable-len...
For communicating within the same office, in the mid-1990's Windows began to support baud rates of 115K max even though the fastest speed the phone line could support was 56K on a good day. It still took years as common modem performance rose from 300baud to 2400baud to 9600baud and eventually 56K. Windows then allowed for connecting two modems in "parallel" using two separate phone lines simultaneously in order to reach 115K for those who dared. Direct COM-port-to-COM-port could do the 115K using a single high-quality RS-232 cable if both PC's were within about 30 feet of each other.
You needed a modem when the remote PC was too far away for direct digital communication between com ports. Once the raw data coming in from the PC to the com port had been "modulated" by the modem for transmission over ordinary landlines, distance was no problem since the phone company handled that no differently than an analog voice call. The receiving modem would "demodulate" the signal coming in from the landline so the recieving com port would end up with the same data as if the com ports at both ends were in direct local contact. That's why they are called modems because they MOdulate/DEModulate the communication stream.
Organizations which were needing to be in constant contact across distance often found it more effective to arrange with the phone company to "lease" a "dedicated" landline between two separate locations rather than continuing to use the random-access public POTS network. These leased-lines had no need for a dialtone since they always connected the same two points and there was not going to be any dialing at all.
To communicate between two modems without going over the public phone lines, there will be no dialtone so you need to use the proper AT commands to instruct the modem to do without a dialtone, as well as a few other considerations. It's best to have the specific technical documentation for the exact modem in use at each end, so you can review the full range of AT commands supported. Some modems have more available commands than the occasional computer language or OS. Hyperterminal was a good app, included with Windows up through XP, for using the PC similarly to a not-so-dumb terminal so you can manually send & recieve ASCII characters (or files, etc) in real time through a COM port and thererby send AT commands to the modem on that port to get things going. After installing the modem device drivers from the manufacturer, their modem software or a third party app was the more user-friendly way (compared to Hyperterminal) to get going with dial-up. Whether it was exposed to the user or not, in the apps there was a field containing the "modem string" of specific AT commands that would be sent as needed for default performance or any optional features that the app supported.
In Hyperterminal you need to compose your own specific modem string and send it manually. If you enable echo you will see everything that you send as well as all data coming in.
Using the ideal (AT and related) commands from each PC's COM port to its modem are essential to be able to configure it away from the default requirement for a dialtone, over into the performance needed for a particular dedicated RJ11 cable between two PC's. You want to follow the modem manufacturers guidelines for "leased-line" operation.
This was essential once PC's failed to all ship with a COM port any more. Modems had been miniaturized to the size of an ISA or PCI card and were then available as internal modems with only a RJ11 jack (or two so you could connect an analog telephone too), and more & more there was not a 9-pin COM port on the back of new PC's at all.
Virtual COM ports appeared as part of the internal modem drivers and delivered the data to the modem by responding to the same software as a physical COM port.
So if you were previously connecting directly from a standard industrial device having a standard COM port, to a PC by connecting directly to its own COM port, when the PC died it could be replaced by a newer PC having only a modem (but without a physical COM port). But then you were going to need to add an external modem to the industrial device so you could run an RJ11 cable in place of the previous RS-232 cable. By then external modems were seldom used any more even though dial-up internet was still growing, so there were lots of surplus external modems and RS-232 cables (which often require various specific, sometimes asymmetric pinout wiring to accomodate things like handshakes).
External modems didn't essentially need device drivers since COM ports needed none, stand-alone modems can really get the job done by responding to AT commands as documented.